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 <> 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 <> 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
>>>>
>>>> https://salilab.org/mailman/listinfo/imp-dev
>>>>
>>> _______________________________________________
>>> IMP-dev mailing list
>>>
>>> https://salilab.org/mailman/listinfo/imp-dev
>>
>> _______________________________________________
>> IMP-dev mailing list
>>
>> https://salilab.org/mailman/listinfo/imp-dev
>
> _______________________________________________
> IMP-dev mailing list
>
> https://salilab.org/mailman/listinfo/imp-dev
>