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 <ttarrant(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev