Yakov, I absolutely agree that the idea of trying to support any bullshit that comes to users mind is wrong and harmful.
Indexing of a collection when this collection is a cache value looks useless to me, it is a bad domain model design, we should discourage this. Indexing a map cache values is completely different use case from what we discuss here. With respect to our new binary marshaller, will it be possible to extract value by key from marshalled map? Probably this is impossible. Thus I think we should discourage stuff like this as well. Sergi 2016-01-22 12:37 GMT+03:00 Yakov Zhdanov <yzhda...@apache.org>: > I have just noticed another question on dev list - whether it is possible > to index of objects that are maps' values and maps, in turn, act as cache > values. This is another point to consider, before taking any decision here. > > One more.. What if collection of objects to index act as cache value? > > From my standpoint it will be pretty complex to implement this in a > seamless manner without limitations of any kind. > > --Yakov > > 2016-01-21 20:27 GMT+03:00 Sergi Vladykin <sergi.vlady...@gmail.com>: > > > I think this feature can be implemented. > > > > As far as I understand user will not need to clone the collection or do > > anything else from what he does now. > > We well have to drop all the collection items from that separate table > and > > add them again on update. Of course we can try to apply some heuristics > > like comparing contents of old collection and new one and add/drop > changed > > items. > > > > Anyways complex things like collection proxy looks like an overkill here, > > since as Yakov already pointed out the actual value of this feature will > be > > quite limited. Lets keep it simple. > > > > Sergi > > > > 2016-01-21 13:37 GMT+03:00 Yakov Zhdanov <yzhda...@apache.org>: > > > > > This may be a good feature, but I don't think it will be widely used. I > > > understand that Ignite users want to have their objects stored exactly > in > > > the format they are used in the application's BL, but in most cases I > > think > > > that users would benefit if they split they objects. > > > > > > For performance considerations I would recommend to store these types > > > separately: > > > 1. gets/puts to main-type cache will be much faster - no excessive > > > serializations/deserializations and, most probably, network overhead. > > > 2. dependent collection modification will be the fastest possible > > > 4. colocation is still here - Ignite can store > > > 3. collection item modification is seamless (let's say you need to > modify > > > "count" of some row of the Order) > > > > > > If we choose the way you suggest... Well, this makes me think of > > > Hibernate-like approaches with sessions, collections mappings and > > proxies. > > > I think this will require us to implement collection wrappers and > proxies > > > in order to efficiently detect modifications. Btw, we can track such > > > changes with BinaryObjects methods - BinaryObject may act as a proxy. > > > > > > Any thoughts? > > > > > > --Yakov > > > > > > 2016-01-21 5:39 GMT+03:00 Dmitriy Setrakyan <dsetrak...@apache.org>: > > > > > > > Igniters, > > > > > > > > I would like us to consider support for indexes into collections > > (lists, > > > > sets) for object fields. I think we can support it by storing > > collections > > > > internally in a separate cache and create a special index for it. > > > > > > > > For example: > > > > > > > > - Create special type of index annotation and config for inner > > > > collections > > > > - Internally, store collection as an additional table with a > > synthetic > > > > foreign key. > > > > - Have user explicitly do a join between 2 tables when he needs to > > > > select something > > > > > > > > The only question I still have is how to handle modifications to > > > > collections. Our current cache access approach would require user to > > > clone > > > > a collection whenever adding or removing elements in it, which can > get > > > > quite expensive. > > > > > > > > Thoughts? > > > > > > > > D. > > > > > > > > > >
