13:07:30 <gsmet> #startmeeting
13:07:30 <jbott> Meeting started Tue Jun 19 13:07:30 2018 UTC.  The chair is gsmet. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:07:30 <jbott> Useful Commands: #action #agreed #help #info #idea #link #topic.
13:07:43 <gsmet> #topic Progress Davide
13:08:15 <DavideD> I spent most of the time trying to upgrade Neo4j and I finally figure out the solution yesterday
13:08:40 <DavideD> One problem was related to create the modules for wildfly
13:09:00 <DavideD> and the second one was that, after the upgrade, I could replicate the error we have on Travis
13:09:15 <gsmet> ah that is good news, sort of :)
13:09:45 <DavideD> Really anonying issue, it seems the query doesn't work with the latest version of the server
13:10:09 <DavideD> I'm not sure why it was working before though
13:10:20 <DavideD> Anyway I figure out an alternative that should work
13:10:31 <DavideD> I should be able to send a PR between today and tomorrow
13:10:42 <gsmet> that's very good news
13:11:07 <DavideD> That is what kept me busy most of the time
13:11:56 <DavideD> We also included some improvements on error messages
13:12:21 <DavideD> And some other minor issues
13:13:09 <DavideD> There is also a PR for Apache Ignite about supporting functions for the HQL queries
13:14:00 <DavideD> It doesn't actually update the hql-parser project but it seems to work for Ignite and I think I'm going to include it anyway considering that it is a separate project
13:14:48 <gsmet> yeah I don't think we should put much effort in the hql-parser considering it will go away with 6
13:14:58 <DavideD> I also had a quick chat with Andrea about the latest ORM, it seems that it's now in a place where I can start to experiment with it
13:15:09 <DavideD> I think that's all
13:16:01 <gsmet> #topic Next 2 weeks Davide
13:16:01 <DavideD> Next week I will be on PTO so I will try to finish the Neo4j intergrations for this week
13:16:24 <DavideD> Probably before so that we can make a release
13:16:31 <fax4ever> +1
13:17:07 <DavideD> That's all from me
13:17:11 <gsmet> ok, thanks
13:17:18 <gsmet> #topic Progress Fabio
13:17:55 <fax4ever> I worked with issue for enabling and supporting transaction on Infinispan remote interface.
13:18:25 <fax4ever> Implementation was pretty straightforward,
13:18:35 <fax4ever> because when you instantiate the Hot Rod driver you can specify also a TransactionManagerLookup.
13:18:45 <fax4ever> If you are curious, you can see this commit on my branch:
13:18:53 <fax4ever> * https://github.com/fax4ever/hibernate-ogm/commit/1574aea555ba1bd9effc86dcc064c894b2357884.
13:19:05 <fax4ever> At the moment transaction are supported only if cache has this configuration:
13:19:10 <sannegrinovero> fax4ever, did the Infinispan team fix the issues you reported?
13:19:24 <fax4ever> They did with success
13:19:38 <fax4ever> At the moment transaction are supported
13:19:47 <fax4ever> * Pessimistic locking
13:19:53 <fax4ever> * Repeatable read as isolation level
13:20:01 <fax4ever> * Transaction mode NON_XA or NON_DURABLE_XA
13:20:10 <fax4ever> So I had to change also the basic OGM configuration for client side created caches.
13:20:19 <fax4ever> This could be a problem because some TCK tests rely instead on read commited as isolation level!
13:20:47 <fax4ever> With Infinispan 9.3.0.CR1 we have still some issues.
13:20:54 <fax4ever> But Pedro solved them!
13:21:03 <fax4ever> ISPN-9288
13:21:14 <fax4ever> and ISPN-9289
13:21:22 <fax4ever> From my tests I can say that with Infinispan 9.3.0.Final transactions should work.
13:21:29 <fax4ever> If you are intrestead, you can find my test projects here:
13:21:36 <fax4ever> https://github.com/fax4ever/infinispan-play/tree/master/infinispan-remote-transaction
13:21:44 <fax4ever> https://github.com/fax4ever/infinispan-play/tree/master/infinispan-jboss-transaction
13:21:54 <fax4ever> Moreover I applied clustered counters to implement @SequenceGenerator for Infinispan remote.
13:22:02 <fax4ever> If the id source strategy is Sequence:
13:22:09 <fax4ever> * Now the counter is created at boot time (SessionFactory build time).
13:22:16 <sannegrinovero> awesome. So what is missing to merge this all?
13:22:16 <fax4ever> * Now the counter is generated using a clustered counter.
13:22:32 <fax4ever> we merged it
13:22:35 <DavideD> sannegrinovero, it's already merged
13:22:48 <fax4ever> Meanwhile I left the old cache implementation for @TableGenerator strategy!
13:23:03 <fax4ever> Furthermore I worked with the update of integration tests to use WildFly 13.0.0.Final.
13:23:14 <fax4ever> Here there was an issue caused by the presence of a not compatible version of Hibernate Search (10.0.1.Final).
13:23:23 <fax4ever> Unfortunately this module is pointed by the same alias slot used by OGM '10.0'.
13:23:34 <fax4ever> We decided to use the full version name as slot name, but only as a temporary solution!
13:23:42 <fax4ever> In fact we would prefer instead continue to using the old alias:
13:23:49 <fax4ever> the one composed with only major and minor version.
13:23:52 <fax4ever> right?
13:24:30 <fax4ever> Finally I worked to integrate Scott's WildFly NoSql project with Hibernate OGM.
13:24:40 <fax4ever> The main idea here is to use WildFly NoSql to create the datastore client instances,
13:24:50 <fax4ever> then to inject them in the datastore providers using JNDI standard.
13:24:59 <sannegrinovero> could you not simply reuse the Search version provided by WildFly ?
13:24:59 <fax4ever> The benefit could be the one that we have the capability to configure the datastore client using a WildFly subsystem.
13:25:10 <fax4ever> no we can't
13:25:32 <fax4ever> becose 10.0.1 requires ORM 5.3.1
13:25:37 <fax4ever> because
13:25:56 <fax4ever> and current version of OGM is not compatible with ORM 5.3.0
13:26:05 <fax4ever> there is an issue about it
13:26:08 <gsmet> well, we could upgrade to 5.3.1 then use Search from WF
13:26:33 <fax4ever> right but before we need to upgrade ORM to 5.3.1
13:26:54 <fax4ever> see OGM-1490
13:26:57 <gsmet> yeah sure but that should be easy?
13:27:08 <fax4ever> I didn't try
13:27:15 <sannegrinovero> so I recommended to not upgrade to 5.3.1 as it's a lot of work to reconfigure all tests to the new JTA platform
13:27:19 <fax4ever> but the SPIs are changed again :(
13:27:24 <sannegrinovero> - which we reverted in ORM 5.3.2 -
13:27:35 <gsmet> ah OK
13:27:43 <fax4ever> ok so we have to wait to 5.3.2 ORM
13:27:46 <fax4ever> :P
13:27:47 <sannegrinovero> but you could use ORM 5.3.0 as main dependency, yet use the 5.3.1 version within WildFly
13:28:12 <fax4ever> right
13:28:31 <fax4ever> we use 5.3.0 ORM module for acutal version of OGM
13:29:25 <fax4ever> Continuing on WildFly NoSql integration topic
13:29:34 <fax4ever> The good news is that WildFly NoSql is compatible with our driver modules and it is also agnostic about the actual driver version used.
13:29:47 <fax4ever> So, until the driver is still compatible with WildFly NoSql, then we can reuse the same release of WildFly NoSql!
13:30:07 <fax4ever> thank you smarlow :)
13:30:17 <fax4ever> If you are interested in the demo projects, you can find here:
13:30:25 <fax4ever> * https://github.com/fax4ever/ogm-wildfly-play/tree/master/hibernate-ogm-wildfly-mongodb-play
13:30:32 <fax4ever> * https://github.com/fax4ever/wildfly-play/tree/master/wildfly-nosql-play
13:30:40 <fax4ever> Currently I've finished the implementation for MongoDB. I will add the support for Neo4J too.
13:30:47 <fax4ever> This bring us to progress topic. Thank you!
13:30:50 <sannegrinovero> thanks I'll have a look :)
13:31:14 <gsmet> #topic Next 2 weeks Fabio
13:31:18 <fax4ever> Thank you!
13:31:30 <fax4ever> First of all, like I said before, I'm going to finish the issue of supporting jndi property client.
13:31:43 <fax4ever> I'll take one day at most
13:31:55 <fax4ever> After that maybe we can release the 5.4.0.Beta2! WDYT Davide? ;)
13:32:09 <fax4ever> Moreover I would like back to work with OpenShift Hibernate Demo,
13:32:20 <fax4ever> it's been a long time since we last worked on it :(
13:32:28 <DavideD> I think we can release even without it, really. But I don't have strong preferences
13:32:39 <fax4ever> +1
13:33:05 <fax4ever> Finally maybe we can arrange a dedicated BlueJeans to talk about:
13:33:15 <fax4ever> * Evolution and next steps of Hibernate OGM.
13:33:22 <fax4ever> Because all ours recent ideas... I think that they have already been made.
13:33:34 <fax4ever> This is all about my progress.
13:33:41 <fax4ever> Thank you!
13:34:14 <gsmet> thanks
13:34:20 <gsmet> #topic Progress Guillaume
13:34:25 <sannegrinovero> +1 to make sure we can release the Hot Rod bit with transactions fast :)
13:34:33 <gsmet> so on the HV front:
13:34:44 <gsmet> - I worked on validating the support of JDK 11
13:35:09 <gsmet> and removed some stuff deprecated in Java 10
13:35:18 <gsmet> so the codebase is pretty clean from this point of view
13:35:34 <gsmet> - I worked on polishing and getting in Marko's PRs
13:35:49 <gsmet> . the reflection abstraction PR which paves the way for JSON support is in
13:36:06 <gsmet> . the getter selection strategy PR should follow shortly
13:36:32 <gsmet> . the next big PR will be JSON support but I don't expect having to review it for at least 2 weeks
13:37:00 <gsmet> - this morning, I pushed a PR to WF to remove HV 5.3 and BV 1.1
13:37:16 <gsmet> on the Search front:
13:37:24 <gsmet> - I reviewed a couple of PRs from Yoann
13:37:46 <gsmet> - I'm back working on the nested documents PR
13:38:08 <gsmet> on the ORM front:
13:38:38 <gsmet> - I took a look at a couple of bytecode enhancement issues, looks like the issues are related to the current design so hard to solve
13:38:48 <gsmet> but at least we have an idea of what the issue is
13:39:18 <gsmet> - I try to keep an eye on the PR stream but, apart from simple ones, it's hard to decide what to do without having Steve handy
13:39:30 <gsmet> that's it for my last 2 weeks
13:39:38 <gsmet> #topic Next 2 weeks Guillaume
13:39:49 <gsmet> the HV side should be quiet
13:39:58 <yrodiere> gsmet: ... :p
13:40:03 <gsmet> the existing PR are polished
13:40:08 <gsmet> PR*s*
13:40:33 <gsmet> and there is quite a lot of work to get the JSON support into shape
13:40:44 <gsmet> I will probably discuss it a bit with Marko but it should be it
13:41:08 <gsmet> so I plan to work mostly on Search with a bit of ORM on the side (~ 1 day a week)
13:41:22 <gsmet> will have to discuss with Yoann what would be the next steps for me on Search
13:41:28 <gsmet> that's it for me
13:41:35 <gsmet> #topic Progress Sanne
13:41:56 <sannegrinovero> hi all, so I've been initially spending a bit of time on an OGM presentation
13:42:15 <sannegrinovero> and some brainstorming with emmanuel about priorities et all
13:42:31 <sannegrinovero> but mostly spending time still on the ORM side of things and how it's suppoed to be backwards compatible
13:42:58 <sannegrinovero> on more interesting aspects, I've been playing with Graal and stratoVM to see what it would take to get our libraries to work on it
13:43:20 <sannegrinovero> so the bad news is that to get it all to work on "binaries" would be a very substantial effort
13:43:39 <sannegrinovero> the good news is that I could speedup bootstrap by a factor 8X by using a mixed mode
13:43:49 <sannegrinovero> so compiling some dependencies in binary images
13:43:58 <sannegrinovero> (specifically the less troublesome ones)
13:44:16 <sannegrinovero> while still using things like hibernate-orm and the user's entity in traditional jars.
13:44:39 <sannegrinovero> in the next few weeks..
13:44:59 <sannegrinovero> gsmet ^
13:45:12 <gsmet> #topic Next 2 weeks Sanne
13:45:17 <sannegrinovero> so those experiments forced me to look at many of our dependencies with jdeps
13:45:35 <sannegrinovero> I'll polish my experiments into a well defined list of JIRAs
13:46:00 <sannegrinovero> as e.g. some small changes in various of our libraries would make work better in Jigsaw
13:46:24 <sannegrinovero> I'll also keep an eye on ORM, like gsmet is doing
13:46:41 <sannegrinovero> in particular looks like I'll have to challenge some spec decisions & the TCK
13:46:56 <sannegrinovero> as we had to make a change which is extremely unpopular for end users :/
13:47:50 <sannegrinovero> I hope to get to play with OGM/Infinispan a bit more, maybe update our demos to use that and propose it at some conferences.
13:47:54 <sannegrinovero> that's all for me.
13:48:01 <fax4ever> +1
13:48:18 <gsmet> #topic Progress Yoann
13:48:52 <yrodiere> I started with support for "minimumShouldMatch' on boolean queries
13:49:09 <sannegrinovero> ah well forgot to complain about all JDK related work but that's no interesting news anymore I guess :)
13:49:50 <yrodiere> essentially that allows someone to define that in the query "foo:text bar:otherText", if the minimum is set to one, then either clause should match, and if set to 2 both clauses should match
13:50:28 <yrodiere> a user asked a question about it the other day, and it turns out the lack of this is quite annoying if you need it, especially with the ES integration
13:50:40 <yrodiere> anyway, PRs are there for 6
13:50:48 <yrodiere> and I backported it to 5
13:51:07 <yrodiere> I think I'll merge only a limited part of it into 5, due to the weird syntax my solution required
13:51:27 <yrodiere> the other big topic I worked on was support for fine-grained dirty checking in Search 6
13:52:00 <yrodiere> which should be a little bit better than in 5, in particular in cases where multiple entities depend on the same entity, but on different fields
13:52:37 <yrodiere> (it's essentially about only reindexing an entity when properties that are relevant to the indexing process changed-
13:52:41 <yrodiere> )
13:53:12 <yrodiere> I also did a few quick reviews on HV, and a few simple cleanup PRs for Search 6
13:53:18 <yrodiere> next two weeks...
13:53:25 <gsmet> #topic Next 2 weeks Yoann
13:54:04 <yrodiere> I'd really want to close the automatic reindexing topic, or at least to have something finalized for us to discuss during our F2F
13:54:27 <yrodiere> I've been working on support for ignoring properties even though they are used when indexing, and should submit a PR
13:54:34 <yrodiere> next will be support for transient properties
13:55:26 <yrodiere> and if possible, I'd like to work on more advanced support for specifying what to reindex when an entity changes, in particular to address cases where a static tree of dependencies is not enough, and something more dynamic is needed
13:55:43 <yrodiere> That should be plenty for two weeks
13:55:52 <yrodiere> That's all
13:55:56 <gsmet> ok, thanks
13:56:19 <gsmet> anything else to discuss or should I close the meeting?
13:56:26 <fax4ever> It's ok for me
13:56:29 <DavideD> Not from me
13:56:44 <yrodiere> emmanuel, nothing new?
13:57:07 <emmanuel> The only think I woudl point out is the thread on the microprofile mailing list
13:57:13 <emmanuel> about a new data access layer
13:57:31 <emmanuel> what your thoughts are would be interesting
13:58:06 <fax4ever> +1
13:59:09 <gsmet> emmanuel: maybe send an email to the internal list?
13:59:31 <gsmet> ok, let's close this meeting, thanks everyone
13:59:37 <gsmet> #endmeeting