ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yakov Zhdanov <yzhda...@apache.org>
Subject Re: supporting collection indexes
Date Thu, 21 Jan 2016 10:37:15 GMT
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
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?


2016-01-21 5:39 GMT+03:00 Dmitriy Setrakyan <dsetrakyan@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.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message