class MapScoreState: public RefCountedObject {
public:
typedef fancy_crap Key;
typedef more_fancy_crap Value;
//! Initialize the table to index on the attributes in at
/** \param[in] pcs The container of particles to index in the table
\param[in] at The set of attributes to index on*/
MapScoreState(ParticleContainer *pcs, const Attributes &at);
//! Get the particles matching v
Particles get_particles(const Values &v) const;
//! Get the particle matching v
/** \throw InvalidStateExpeption if more than one particle matches
*/
Particle *get_particle(const Values &v) const;
//! Also would have the score state update method to force an update
};
typedef MapScoreState<Int> AtomIndexMap;
AtomIndexMap *myindexmap= new AtomIndexMap(myparticles,

AtomIndexMap::Key(AtomDecorator::get_index_key()));
myindexmap->before_evaluate(-1); // we might want to add an update
method to ScoreState

Particle *atom10 = myindexmap->get_particle(AtomIndexMap::Value(10));

For python, we would have to create a bunch of the maps with pre-
chosen types (i.e. IntMapScoreState, IntStringMapScoreState).

Daniel - we all know how to run for loops ;)
I just thought it make sense to have something more efficient :)
On Tue, 9 Dec 2008, Daniel Russel wrote:

On Dec 9, 2008, at 9:29 AM, Keren Lasker wrote:

For the 26S project we currently do:
get particle by name

How could we beat something like:

[x for x in myparticles if x.has_attribute(name) and
x.get_value(name)

==
"myname"]
with an SQL query?

get a set of particles within a residue number range

again, some variant on:
[x for x in molecular_hierarchy_get_by_type(root,
MolecularHierarchyDecorator.RESIDUE) if
ResidueDecorator(x).get_index() > lb and
ResidueDecorator(x).get_index()
<ub]
or C++, something like

1. it can interact with the hierarchy - give me the
residues range
within this protein for example - so we should probably also
allow for

a
hierarchy handle in the interface.

2. we might want to ask residue range + some other property
such as

have

structural coverage or do not. Therefore I think that a sql
type

string can

be more general than a list of attributes - because you do
not know

how they
are related.

But the added complication is why I would suggest sticking
with C++ or
python. Lambda functions or list comprehensions support very
general

logic

(more so than SQL) and allow you to leverage existing code.
SQL would

make

it really hard to use any of the existing functionality and
require

lots of

things be exposed in another language. For example, try to
find all

particles close to a point in SQL? It is kind of ugly.

On Tue, 9 Dec 2008, Daniel Russel wrote:

In general, I think having queries on the whole collection of
particles
in the model is not a good idea (since other people's code,
restraints or

states can add particles to the model and you can never be
sure what

those
look like).

There is already functionality to search a Hierarchy
(although it is
more aimed at C++-- we could use a python interface which
takes takes

a

python lambda function to make it more convenient to use in
python).

And

python has all sorts of features for searching a list (and C
++ has a

few).

It is not clear to me that we could provide an interface
that is

general and much more concise.

As a slight simplification for python users, we could
provide a

function which takes a list of key, value pairs (with keys of
arbitrary

type) and a container. It is a bit messier to provide this
interface

in C++
as we would have to have a separate list per type.
Another thing to simplify such search would be a

"DefaultValuesDecorator" which wraps a particle and pretend
it has

all

attributes, just providing default values for missing ones.
This

would

obviate the need to check for an attribute before matching
against

it.
What sort of queries do you all do?
On Dec 9, 2008, at 8:43 AM, Dina Schneidman wrote:

Hi,

I need this too (surprisingly). Usually I do it with
mapping between

the particle and the attribute.

It is simple. however it is unclear where should we put
such a

mapping. Putting it in a model

could be the best, however not everyone needs it. So it
means

somewhere else or extending the Model to ProteinModel?
Dina
P.S. skype me, we can talk about it

On Tue, Dec 9, 2008 at 7:03 AM, Keren Lasker <kerenlATsalilab.org>

wrote:

hi all,

Frido and I find ourselves many times need to query
particles based

on
attribute values.

Few such examples: a protein with a specific name,
particles with a

specific
residue range.

I think that it would be very useful to have something
similar to

SQL
queries on the particles DB.

Bret might had something similar implemented - but it is
probably

obsolete.
IMP.Atom will probably need such functionality as well.
has anyone took a look at that before ?
thank you,
Keren.
_______________________________________________
IMP-dev mailing list
IMP-devATsalilab.orghttps://salilab.org/mailman/listinfo/imp-dev