Hi Tristan, Thanks for writing that up the document, one (long) comment:
I think the wiki is not very clear on the difference between type and content type. It often uses the word type when it really means content type. IOW, a cache can store instances of a single type (e.g. Person) or it can mix it up by storing multiple types (e.g. Person, Car...etc), but that's not the same as the content type (e.g. JSON or XML). In theory, you could have: 1. A single type and a single content type, e.g. Person instances, stored as JSON. ^ This option makes the most sense to me. We should strive to promote this. 2. A single type and multiple content types, e.g. Person instances, somes stored as JSON, some as Protobuf binary. ^ Is this realistic? I'd imagine that even if you have difference input devices, you'd try to find the format that's common denominator. However, maybe due to lack of capabilities or performance reasons, you might decide to store differently? Also, for querying to work, you'd have to be able to index different source types. 3. Multiple types and a single content type, e.g. Person and Car instances, all stored as JSON. ^ We've had discussions about this in the past: In general I'm in favour of a single type per cache. However, there are some limitations to such set up, e.g. querys can only execute against 1 cache (AFAIK unless this limitation has changed?). So, such limitations can force users to add multiple types in the same cache. 4. Multiple types and multiple content type, e.g. Person and Car instances, Persons stored as JSON, Cars stored as XML. ^ If you are inclined to store multiple types in the same cache, this could certainly happen. Thoughts? Cheers, -- Galder Zamarreño Infinispan, Red Hat > On 21 Jun 2016, at 09:49, Tristan Tarrant <ttarr...@redhat.com> wrote: > > Hi all, > > I've created a wiki [1] for the "compatibility 2.0" ideas we talked > about recently at the query meeting. > > This is mostly a dump of the minutes, so the form is not complete, but > initial comments are welcome. > > > Tristan > > [1] https://github.com/infinispan/infinispan/wiki/Compatibility-2.0 > -- > Tristan Tarrant > Infinispan Lead > JBoss, a division of Red Hat > _______________________________________________ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
