Re: [hibernate-dev] Remove or disable the WildFly feature packs of Hibernate ORM?
o need to > upgrade > >> > >> our integrations with a different Validator, a different CDI - > none of > >> > >> these are provided by WildFly yet. > >> > >> > >> > >> I see several options: > >> > >> A] I could disable the feature pack generation and its integration > >> > tests. > >> > >> B] Keep generating and releasing a knowingly broken feature pack, > >> > >> disable its integration tests, document this is work in progress. > >> > >> C] Delete all this stuff > >> > >> > >> > >> Frankly it's tempting to just delete it all: WildFly has switched > to a > >> > >> new model which replaces the "feature pack" notion we have, so > even if > >> > >> Wildfly were to provide an Jakarta EE 9 build for us to run > >> > >> integration tests sometimes soon I'm sadly quite certain that we'll > >> > >> have to rethink how these packs are generated, and if it's still > worth > >> > >> for us doing this. > >> > >> > >> > >> Any thoughts? > >> > >> > >> > >> Thanks, > >> > >> Sanne > >> > >> ___ > >> > >> hibernate-dev mailing list > >> > >> hibernate-dev@lists.jboss.org > >> > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > >> > >> > >> > ___ > >> > hibernate-dev mailing list > >> > hibernate-dev@lists.jboss.org > >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev > >> > > >> > > >> ___ > >> hibernate-dev mailing list > >> hibernate-dev@lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > >> > > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev -- FABIO MASSIMO ERCOLI HIBERNATE TEAM fabio.erc...@redhat.com fa...@hibernate.org <https://red.ht/sig> ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] HHH-13604 Define some Byteman rules to check what APIs are used at runtime: next steps?
Hi guys, the activity was very interesting, so I would like to thank Sanne who had the idea and led the scope of the activity and thanks to Andrea who gave me some nice ideas to improve the work. With [this pull request]( https://github.com/hibernate/hibernate-orm/pull/3040) we have now rules to check: Read annotations Class.forName Other Java reflection APIs Create proxy Patter#compile As a follow up (and probably it won’t be the only one) I created the issue: https://hibernate.atlassian.net/browse/HHH-13669. So far I’ve been involved in Hibernate OGM and Hibernate Search, so I don't have a very deep knowledge of Hibernate ORM. So I would like to ask you: what are the next steps? And… is there something I can do to help? Meanwhile I’ll be back to work on Hibernate Search. The integration with Infinispan is still waiting… Have a great weekend Fabio ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] Hibernate OGM 5.4.0.CR1 is out
Hibernate OGM 5.4.0.CR1 is ready! Some improvement was the support of Infinispan remote transactions over HotRod client, java.time field types and MongoDB ReadConcern strategy. All the details in the blog post: http://in.relation.to/2018/10/01/hibernate-ogm-5-4-CR1-released/ Thanks, Fabio ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] Hibernate OGM 5.4.0.Beta2
We're happy to announce the release of Hibernate OGM 5.4.0.Beta2. You will find: * Support for Neo4j indexes * Server tasks support for Infinispan Remote * Upgrade to Hibernate ORM 5.3.2.Final ...and more. All the details in the blog post: http://in.relation.to/2018/07/05/hibernate-ogm-5-4-Beta2-released/ All the best, Fabio ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] HIbernate OGM 5.4.0.Beta1 is out
HIbernate OGM 5.4.0.Beta1 is ready! Some improvement was the version upgrade for Hibernate ORM 5.3.0.Final and Hibernate Search (5.10.0.Final), the support for Infinispan Remote native and JPQL queries (without requiring Hibernate Search) and the use of cluster counters for local caches when generating sequences with Infinispan Embedded. All the details in the blog post: *http://in.relation.to/2018/05/25/hibernate-ogm-5-4-Beta1-released/ <http://in.relation.to/2018/05/25/hibernate-ogm-5-4-Beta1-released/>* Thanks, Fabio -- FABIO MASSIMO ERCOLI HIBERNATE TEAM fabio.erc...@redhat.com fa...@hibernate.org <https://red.ht/sig> ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] OpenShift Hibernate demo: Next Steps
Hi, Andrea and me are starting the next sprint on OpenShift Hibernate demo. Based on the feedbacks we received, we have prepared this TODO list for the next steps: * Provide feedback on Infinispan OCP template * Extract template paramters and environment variables into secrets and config Maps. * Refactoring provisioning scripts based on Tristan suggestion: https://github.com/jboss-container-images/datagrid-7-image/blob/datagrid-services-dev/Makefile https://github.com/jboss-container-images/datagrid-7-image/blob/datagrid-services-dev/Jenkinsfile * Discuss Hibernate statup optimization on OCP. * Implement authentication and authorization. * Infinispan remote task to update the board (in future Stored procedure JPA) * Search / Query on messagges * Full text Search / Analytics on message content * Pipeline / DevOps ( Jenkins ) WDYT about it? Suggestions and ideas are more then wecolme. Cheers Fabio -- FABIO MASSIMO ERCOLI fabio.erc...@redhat.com fa...@hibernate.org <https://red.ht/sig> ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] Hibernate OGM 5.3.1.Final released
Hibernate OGM 5.3.1.Final is ready! This is a maintenance release fixing issues related to native queries pagination and projection. All the details in the blog post: *http://in.relation.to/2018/03/29/hibernate-ogm-5-3-1-Final-released/ <http://in.relation.to/2018/03/29/hibernate-ogm-5-3-1-Final-released/>* Thanks, Fabio -- FABIO MASSIMO ERCOLI Senior Software Engineer - Hibernate & Data Platform Red Hat <https://www.redhat.com/> fabio.erc...@redhat.comM: (+39)-329.8681441 <http://redhatemailsignature-marketing.itos.redhat.com/> <https://red.ht/sig> ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Hibernate OGM mapping for "server side Hibernate Search" via Infinispan Remote
Hi Sanne, what you speak of in my opinion is a very very cool feature. Moreover server-side indexes (and remote dialect) are more suitable for Openshift applications. Using standard javax.persistence.Index APIs could be a very nice alternative to avoid confusion with Hibernate Search client side usage. For the problem (B) maybe we can extend the API (adding a some non standard annotation, at least one for the analyze). I'm really interested in this development. Thank you. Fabio On Wed, Mar 14, 2018 at 12:52 PM, Sanne Grinovero wrote: > Hi all, > > this one is a very desirable feature, yet tricky as there's high > chances of ambiguity and confusion for end users. > > > # Infinispan Remote indexing > > Infinispan embeds the Hibernate Search engine, and uses it to index > data being inserted in any cache having indexing enabled. As you know > Infinispan can be used to store Java POJOs, which get serialized using > JBoss Marshalling - or encoded into Protobuf entries using Infinispan > Protostream as helper layer. > > Hibernate OGM supports both modes, one meant for "Infinispan Embedded" > and one for "Infinispan Remote" as that's what each encoding strategy > is suited for. > > > # Protobuf & indexing > > Protobuf is a well defined format with plenty of documentation which > focuses on a "schema" of the encoding; Hibernate OGM is able to > generate such schemas dynamically and will generate encoders and > decoders which follow the encoding guidelines for Java objects. > > The meta schema of protobuf is not super flexible, yet there's the > option of annotating the Protobuf schema elements using "annotations" > in comments. > Protostream allows inserting Hibernate Search annotations directly in > these comments and will use them to generate the server side indexing > configuration, implicitly also allowing such properties to be queried > using indexed. > > For example you might have this string literally within the comments: > "@Field(store = Store.YES, analyze = Analyze.YES)" > > A full example of schema can be found here [1]. > (The Infinispan documentation is a bit sparse on this as they > encourage people to use another code gen tool, best refer to tests as > examples when working for OGM) > > > # What should OGM users experience? > > A naive solution would be to allow people to use the Hibernate Search > annotations on their JPA entities, and we have OGM copy these into the > generated schema; there's a number of problems with that: > - not all such annotations "translate" equally well [2] > - there's a mismatch between JPA properties and underlying encoding fields > - if I run a FullTextQuery do I expect it to work remotely? > - what if I want to use Hibernate Search locally as well or instead? > - references to local classes obviously won't work (custom > fieldbridges, analyzers, etc..) > > An alternative is to look at these as "indexes" of the underlying > store, so we'd use them to hint the Infinispan server about user > provided hints such as those generated by `javax.persistence.Index`. > I do think this is the cleaner approach, yet has two drawbacks: > A- I guess ORM might implicitly generate some indexes in its metadata > which the user might not have explicitly asked; e.g. accelerate unique > constraints and foreign keys; it's possible these might not be as > useful as expected in the Infinispan case. > B- we won't be able to leverage the awesome full-text capabilities :-( > > I believe A is something we could ignore for now and revisit if > there's actual demand. > > B is also not urgent, yet disappointing limitation as this capability > is a distinguishing feature of this NoSQL. Would we agree that > exposing such full-text capabilities would best be let to an ad-hoc > backend in Hibernate Search 6? > > > Thanks, > Sanne > > 1 - http://blog.infinispan.org/2018/02/restful-queries- > coming-to-infinispan-92.html > 2 - https://github.com/infinispan/infinispan/blob/master/remote- > query/remote-query-server/src/main/java/org/infinispan/ > query/remote/impl/indexing/IndexingMetadataCreator.java#L31 > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] Hibernate OGM 5.3.0.Final released
Hibernate OGM 5.3.0.Final is ready! We worked to make it compatible with Hibernate ORM 5.2.13.Final. All the details in the blog post: http://in.relation.to/2018/02/20/hibernate-ogm-5-3-Final-released/ Thanks, Fabio ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] Hibernate OGM 5.3 CR1 released
HIbernate OGM 5.3 CR1 is ready! The major improvement was the version upgrade for Hibernate ORM (5.2.13.Final) and Hibernate Search (5.9.0.Final). The application of Clustered Counters, for Infinispan Embedded dialect, has been improved in this version. All the details in the blog post: http://in.relation.to/2018/02/13/hibernate-ogm-5-3-CR1-released/ Thanks, Fabio ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Hiberante OGM Infinispan Remote dialect - Execute the command queue as a single Infispan Remote Server Task
Hi Radim, thank you for the alternative, it is very interesting. I've to study deeply the feature :P Fabio On Mon, Feb 5, 2018 at 9:53 AM, Radim Vansa wrote: > Hi Fabio, > > thinking about the cons, Hot Rod can intelligently pick the server where > should a given key reside, to reduce the number of hops (therefore, > latency). RemoteCache does not expose any way to route according to some > key; feel free to file a feature request in Infinispan JIRA. > > Note that in order to reduce the number of round-trips, Infinispan 9.2 > will support true-async operations: Previously the putAsync et all just > moved the execution to different thread, since 9.2.0.CR2 it sends the > request to the wire right await and the response is received through a > CompletableFuture. At this moment multiple requests will need a distinct > TCP connection for each concurrent operation, but this limitation is > likely to be removed in 9.3. The goal is to let you write the batch down > one-by-one using async API and just wait for all the operations to > complete. > > I know this won't help for all the types of operation (a lack of > client-side API sometimes forces OGM to use get() + CAS in a loop). > > I am not trying to talk you out of the remote execution API, just > spreading news about the emerging alternatives. > > Radim > > On 02/02/2018 09:24 AM, Fabio Massimo Ercoli wrote: > > I'm Fabio, nice to meet you. > > > > Speaking of the current implementation of the Infinispan remote dialect > of > > Hibernate OGM, working on issue OGM-1206 and talking with Davide I > noticed > > that the unit of work commands are executed (flushed to datastore) at the > > end of the transaction itself. > > In particular I noticed that the commands are stored in a transaction > > scoped object of type org.hibernate.ogm.dialect. > batch.spi.OperationsQueue. > > > > Instead of perfom one remote invocation for each command in the method > > org.hibernate.ogm.dialect.impl.BatchOperationsDelegator::executeBatch > > maybe we could invoke a proper Infispan Remote Server Task to execute the > > command queue on server side as a bulk operation. > > > > Moving the execution of the server-side command list (Infinispan) we > would > > have the advantage of reducing remote interactions. Moreover and above > all > > the execution of the command queue would be a transactional work unit, on > > which could be apply a Repeteable Read isolation level, for instance. > > > > The solution would not solve the need for an XA client instead, but it > > could be adopted by customers interested in local transactions. > > > > What do you think about it? > > Can I open a Jira issue? > > > > Fabio > > > > -- > Radim Vansa > JBoss Performance Team > > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > -- FABIO MASSIMO ERCOLI Senior Software Engineer - Hibernate & Data Platform Red Hat <https://www.redhat.com/> fabio.erc...@redhat.comM: (+39)-329.8681441 <http://redhatemailsignature-marketing.itos.redhat.com/> <https://red.ht/sig> ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] Hiberante OGM Infinispan Remote dialect - Execute the command queue as a single Infispan Remote Server Task
I'm Fabio, nice to meet you. Speaking of the current implementation of the Infinispan remote dialect of Hibernate OGM, working on issue OGM-1206 and talking with Davide I noticed that the unit of work commands are executed (flushed to datastore) at the end of the transaction itself. In particular I noticed that the commands are stored in a transaction scoped object of type org.hibernate.ogm.dialect.batch.spi.OperationsQueue. Instead of perfom one remote invocation for each command in the method org.hibernate.ogm.dialect.impl.BatchOperationsDelegator::executeBatch maybe we could invoke a proper Infispan Remote Server Task to execute the command queue on server side as a bulk operation. Moving the execution of the server-side command list (Infinispan) we would have the advantage of reducing remote interactions. Moreover and above all the execution of the command queue would be a transactional work unit, on which could be apply a Repeteable Read isolation level, for instance. The solution would not solve the need for an XA client instead, but it could be adopted by customers interested in local transactions. What do you think about it? Can I open a Jira issue? Fabio -- FABIO MASSIMO ERCOLI Senior Software Engineer - Hibernate & Data Platform Red Hat <https://www.redhat.com/> fabio.erc...@redhat.comM: (+39)-329.8681441 <http://redhatemailsignature-marketing.itos.redhat.com/> <https://red.ht/sig> ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
