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.
I integrated the module command factory change in ISPN master earlier today. I was able to run the infinispan hibernate tests and they worked for me with your PR applied. Is there some other thing I needed to run?
And since we know to watch out for the binary compatibility we can make sure it stays that way for the 8.0 Final release.
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@redhat.com
> <mailto:ttarrant@redhat.com>> wrote:
>
>
>
> On 06/08/2015 10:30, Sanne Grinovero wrote:
> > On 6 August 2015 at 03:01, William Burns <mudokonman@gmail.com
> <mailto:mudokonman@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@lists.jboss.org <mailto:infinispan-dev@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@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Radim Vansa <rvansa@redhat.com>
JBoss Performance Team
_______________________________________________
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev