[infinispan-dev] Hibernate ORM 5.0.0.CR4 not working so well with Infinispan 8.0.0.Beta2...

[Radim Vansa]

I have already solved that using filterEntries [1], but that's not end 
of the pain. Another change is ISPN removing 
ExtendedModuleCommandsFactory - I could not get around that with 
Infinispan snapshot. And if Infinispan does not keep fixed API even 
between major versions, these attempts to sync it seem quite futile.

Radim

[1] https://github.com/hibernate/hibernate-orm/pull/1045

On 08/06/2015 04:17 PM, William Burns wrote:
>
>
> On Thu, Aug 6, 2015 at 4:42 AM Tristan Tarrant <ttarrant at redhat.com 
> <mailto:ttarrant at redhat.com>> wrote:
>
>
>
>     On 06/08/2015 10:30, Sanne Grinovero wrote:
>     > On 6 August 2015 at 03:01, William Burns <mudokonman at gmail.com
>     <mailto:mudokonman at gmail.com>> wrote:
>     >> It seems ORM was compiled with a version earlier than Beta1 but
>     then ran
>     >> with Beta2?  The keySet method was changed to return a subclass of
>     >> CloseableIteratorSet with Beta2 to support distributed streams [1].
>     >
>     > BTW that CacheSet API change looks like it was intended to be
>     > backwards compatible? It's not, as we just realised. I you want
>     it to
>     > be backwards compatible you'll have to revert that API change.
>
>      From the ORM version numbers (CR4) I guess we are near endgame and we
>     MUST ensure that ORM works with both Infinispan 7.x and 8.x.
>     Will is it possible to make the signature of the method backwards
>     compatible ?
>
>
> The method is backwards compatible when compiling and running against 
> ISPN 8.
>
> I don't think there is any way here to make this backwards compatible 
> changing only ISPN with varying versions at runtime without adding new 
> methods in ISPN 8 which are identical to keySet, values and entrySet 
> except the return type for them are defined as returning the new 
> CacheSet/CacheCollection interfaces.  The underlying implementation 
> for the duplicates would be identical however.  Without those new 
> methods we wouldn't have access to the more advanced options when 
> using distributed streams unless we manually casted.  This doesn't 
> sound too appealing to me.
>
>     If this is inconvenient, what can be done in Hibernate Infinispan to
>     insulate it from this change ?
>
>
> This code is essentially doing a clear, but can this code live with 
> the semantics of clear [1] that are the same between ISPN 7 & 8?  I am 
> guessing not.
>
> We could add a utility method in ISPN 7 & 8 that is defined as 
> returning a ClosebaleIteratorSet/Collection that would be identical in 
> both versions that we could also do [2].  Then if ORM calls the 
> appropriate static method instead of keySet, values, entrySet it would 
> be backwards runtime compatible as well.
>
>
>     Still, I'm wondering whether hibernate-infinispan shouldn't be
>     subclassed into multiple versions so that we can be a bit more liberal
>     with some changes.
>
>
> This does hamper changes quite a bit.  This change was pretty minor, I 
> can't imagine if they are using some class/method that we are removing 
> in ISPN 8.
>
>
>     Tristan
>
>     --
>     Tristan Tarrant
>     Infinispan Lead
>     JBoss, a division of Red Hat
>     _______________________________________________
>     infinispan-dev mailing list
>     infinispan-dev at lists.jboss.org <mailto:infinispan-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> [1] 
> https://github.com/infinispan/infinispan/blob/7.2.x/core/src/main/java/org/infinispan/Cache.java#L329 
>
> [2] https://gist.github.com/wburns/c3d3d95483d35be4b8c6
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


-- 
Radim Vansa <rvansa at redhat.com>
JBoss Performance Team