I think IndexModel is the best solution, but in C++. having python and c++ is more than enough, we don't want to support something else. I suggested extending the Model because of the update reason, in this case you can update the indexing when you add/remove particles.
On Tue, Dec 9, 2008 at 9:29 AM, Keren Lasker kerenl@salilab.org wrote: > For the 26S project we currently do: > get particle by name > get a set of particles within a residue number range > > > the solution of a function that gets (key,value,container) seems like a good > solution. > However - it can be more complicated : > 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. > > > 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 kerenl@salilab.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-dev@salilab.org >>>> https://salilab.org/mailman/listinfo/imp-dev >>>> >>> _______________________________________________ >>> IMP-dev mailing list >>> IMP-dev@salilab.org >>> https://salilab.org/mailman/listinfo/imp-dev >> >> _______________________________________________ >> IMP-dev mailing list >> IMP-dev@salilab.org >> https://salilab.org/mailman/listinfo/imp-dev > > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev >