I think that in the case of Hot Rod clients we should not use AtomicMaps

Would you agree on try basing the approach on a brand new dialect

and on protobuf schema generation?

Hi all, with Infinispan in embedded mode we used AtomicMaps and FineGrainedAtomicMaps as an alternative way to map attributes and relations. In particular the relations are interesting because in SQL world one would run a query on junction tables, and on Infinispan embedded queries would only be an option on Hibernate Search / Infinispan Query annotated attributes, and also the AtomicMaps allow us to only load the section of relevant data (like on a RDBMs). The difference between the two kinds of AtomicMaps is in the locking level, each similar to the same kind of locking we'd normally have. On Hot Rod, AtomicMaps are not available so we opened (a long time ago) a feature request to implement them for Hot Rod - at least Java clients. Still, we don't have transactions in this case either so the locking benefits are also unavailable. I think that in the case of Hot Rod clients we should not use AtomicMaps, but rather resort to a protobuf schema generation, and essentially use the more traditional "query on jointables" approach. Hot Rod nowadays supports queries, and they can be indexed or non indexed so we could enable indexing on the ad-hoc tables we build for relations mapping, have the user "opt in" for additional indexes, and still allow some level of querying for the fields which have not been indexed; of course w/o join operations. We can generate an appropriate schema and upload it to Hot Rod automatically; that sounds like a great usability improvement for all Java clients dealing with Infinispan/remote, as its schema ads quite some stuff to the learning curve. Still, this automatic generation is a new and challenging field; some notes: - protobuf schemas are generational -> more effective if you can generate the new one based on the existing one - there's a Java encoder by Adrian here: https://github.com/infinispan/protostream - Typically one would need to assign a stable sequence id to each field - previous points will likely want us to dump the output resource somewhere, maybe even persist on Infinispan? On a very different topic, we also typically require from a GridDialect implementor to provide sequence generation capability. I don't see a solution for that over Hot Rod, it doesn't currently have any safe incremental id, but when I asked today I was told that Infinispan 8 might have it; Tristan pointed out you can upload a script and have it run on the server, which in turn has access to the transactions API so this should be possible but doesn't look too easy. Finally, we'll need using the distributed remote iterator for GridDialect#forEachTuple. So my conclusion is that to support Hot Rod we'd be better off to make a completely different GridDialect than the one for Infinispan embedded, as I can hardly see some shared code. Would you agree on try basing the approach on a brand new dialect and on protobuf schema generation? In terms of features, we can implement them all except: - transactions & locks - join queries Thanks, Sanne _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

Hi all, with Infinispan in embedded mode we used AtomicMaps and FineGrainedAtomicMaps as an alternative way to map attributes and relations. In particular the relations are interesting because in SQL world one would run a query on junction tables, and on Infinispan embedded queries would only be an option on Hibernate Search / Infinispan Query annotated attributes, and also the AtomicMaps allow us to only load the section of relevant data (like on a RDBMs). The difference between the two kinds of AtomicMaps is in the locking level, each similar to the same kind of locking we'd normally have. On Hot Rod, AtomicMaps are not available so we opened (a long time ago) a feature request to implement them for Hot Rod - at least Java clients. Still, we don't have transactions in this case either so the locking benefits are also unavailable. I think that in the case of Hot Rod clients we should not use AtomicMaps, but rather resort to a protobuf schema generation, and essentially use the more traditional "query on jointables" approach.

Hot Rod nowadays supports queries, and they can be indexed or non indexed so we could enable indexing on the ad-hoc tables we build for relations mapping, have the user "opt in" for additional indexes, and still allow some level of querying for the fields which have not been indexed; of course w/o join operations. We can generate an appropriate schema and upload it to Hot Rod automatically; that sounds like a great usability improvement for all Java clients dealing with Infinispan/remote, as its schema ads quite some stuff to the learning curve. Still, this automatic generation is a new and challenging field; some notes: - protobuf schemas are generational -> more effective if you can generate the new one based on the existing one - there's a Java encoder by Adrian here: https://github.com/infinispan/protostream - Typically one would need to assign a stable sequence id to each field - previous points will likely want us to dump the output resource somewhere, maybe even persist on Infinispan?

On a very different topic, we also typically require from a GridDialect implementor to provide sequence generation capability. I don't see a solution for that over Hot Rod, it doesn't currently have any safe incremental id, but when I asked today I was told that Infinispan 8 might have it; Tristan pointed out you can upload a script and have it run on the server, which in turn has access to the transactions API so this should be possible but doesn't look too easy.

GridDialect#forEachTuple. So my conclusion is that to support Hot Rod we'd be better off to make a completely different GridDialect than the one for Infinispan embedded, as I can hardly see some shared code.

on protobuf schema generation?

In terms of features, we can implement them all except: - transactions & locks - join queries

Sanne _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev