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
Hey guys,
Please bear with me as I am relatively new to Ignite. But here’s my thoughts:
I have to agree that we can’t jump in an go build anything that comes to mind
but to Sergi’s point about indexing collection objects being pointless I would
take for instance the example of a car dealership
Hey Christos!
I've actually agreed with Dmitriy's proposal (which covers the use case
you've described but with another SQL syntax). It will not require too much
efforts to implement, will not have too complex config, will have clear
performance characteristics. This absolutely makes sense.
But
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
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
