[infinispan-dev] Proposed ISPN 7 compilation incompatibilities with ISPN 6

[William Burns]

On Thu, Mar 13, 2014 at 10:25 AM, Sanne Grinovero <sanne at infinispan.org> wrote:
> Is there a migration guide?
> This should be documented in some wiki page similar to
> - https://community.jboss.org/wiki/HibernateSearchMigrationGuide

I have created https://issues.jboss.org/browse/ISPN-4109 to address
this after the issues are merged in to update the Infinispan upgrade
guide.

Thanks for bringing this up.

>
> On 13 March 2014 12:45, William Burns <mudokonman at gmail.com> wrote:
>> On Thu, Mar 13, 2014 at 8:37 AM, Pedro Ruivo <pedro at infinispan.org> wrote:
>>>
>>>
>>> On 03/13/2014 12:35 PM, William Burns wrote:
>>>> On Thu, Mar 13, 2014 at 8:31 AM, Pedro Ruivo <pedro at infinispan.org> wrote:
>>>>> Hi,
>>>>>
>>>>> #1 and #2 are ok to me but, IMO, the filter package should be in commons
>>>>> module
>>>>
>>>> Sorry I forgot to detail why I said core.  I originally planned for
>>>> commons package as well, however the KeyValueFilter class needs the
>>>> Metadata class, which doesn't live in the commons package.  I didn't
>>>> want to separate the 2 filter classes.  And unfortunately the Metadata
>>>> class relies on other classes in core, so that isn't easy to move over
>>>> either, but doable :(  WDYT?
>>>
>>> can you explain why the metadata is needed? I assumed that the key and
>>> the value were the only objects needed.
>>
>> That is how the design doc was written up :P My guess is so that
>> people if needed can filter out versioned entries or to possibly do
>> some eviction magic since they can try to calculate when the entry
>> would be removed.  Maybe Mircea can shed some additional light.
>>
>>>
>>>>
>>>>>
>>>>> Cheers,
>>>>> Pedro
>>>>>
>>>>> On 03/13/2014 12:07 PM, William Burns wrote:
>>>>>> Recently while working on some ISPN 7 features, there were some public
>>>>>> API inconsistencies.  I wanted to bring these up just in case if
>>>>>> someone had concerns.
>>>>>>
>>>>>> The first few are pretty trivial, but can cause compilation errors
>>>>>> between versions if user code implements these interfaces and defines
>>>>>> types.
>>>>>>
>>>>>> 1. The CacheWriter interface currently defines a delete(K key) method.
>>>>>>    To be more inline with JCache and java.util.collections interfaces I
>>>>>> was hoping to change this to be delete(Object key) instead.
>>>>>> 2. The CacheLoader interface currently defines load(K key) and
>>>>>> contains(K key) methods.  Similar to above I was hoping to change the
>>>>>> K type to be Object to be more inline with JCache and
>>>>>> java.util.collections interfaces.
>>>>>>
>>>>>> This last one is a bit more major, but currently we have 2 classes
>>>>>> that are named KeyFilter.  One that resides in the
>>>>>> org.infinispan.notifications package and another that resides in the
>>>>>> org.infinispan.persistence.spi.AdvancedCacheLoader interface.
>>>>>>
>>>>>> 3. My plan is instead to consolidate these classes into 1 into a new
>>>>>> core org.infinispan.filter package.  I would also move the new
>>>>>> KeyValueFilter class that was added for cluster listeners into this
>>>>>> package and their accompanying implementations.
>>>>>>
>>>>>> The first 2 is currently implemented as changes in
>>>>>> https://github.com/infinispan/infinispan/pull/2423.  The latter I was
>>>>>> going to add into changes for
>>>>>> https://issues.jboss.org/browse/ISPN-4068.
>>>>>>
>>>>>> Let me know what you guys think.
>>>>>>
>>>>>>    - Will
>>>>>> _______________________________________________
>>>>>> infinispan-dev mailing list
>>>>>> infinispan-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>>>
>>>>> _______________________________________________
>>>>> infinispan-dev mailing list
>>>>> infinispan-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>> _______________________________________________
>>>> infinispan-dev mailing list
>>>> infinispan-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev