I've included an example which represents a good reason to provide the
controversial method.
Technically the test is crafted as a static sharding approach but is
using the new API; you can easily figure the same case for a dynamic
sharding case; also considering we're deprecating the older static
s
Hi Hardy,
could you have a look at the following two commits, while I work on a
test as you suggested.
(documentation will follow depending on which one you like best).
In this case I just add the missing method, and I don't think it's
bad, actually the name is fine and while I'm sure you might ha
On 7 Jan 2013, at 5:03 PM, Sanne Grinovero wrote:
> I've tried hard to find an agreement on this, but it seems we're
> wasting time without making progress.
> I'm not happy in ignoring a strong recommendation from any of you,
> very hard choice :-(
In the end it is your call. I tried to give ar
On 2 October 2013 14:34, Emmanuel Bernard wrote:
> On Tue 2013-09-24 14:30, Sanne Grinovero wrote:
>> On 24 September 2013 14:12, Hardy Ferentschik wrote:
>> > 2) remove 'String[] getShardIdentifiers(Class entity, Serializable id,
>> > String idInString)' from ShardIdentifierProvider
>>
>> +1 we
On 7 Jan 2013, at 12:06 PM, Gunnar Morling wrote:
> It adds a bit to the
> index size, but I guess it's the safer/simpler option for the time being.
The index size difference is imo in this case negligible. I would not have been
comfortable with the
required changes in Search in case we had to
Ah, I see. So ISPN is using a custom field holding the user type name and
filtering on that one instead of using the existing OBJECT_CLASS field.
That was the missing puzzle piece I was looking for :) It adds a bit to the
index size, but I guess it's the safer/simpler option for the time being.
2
On 7 October 2013 10:51, Gunnar Morling wrote:
> 2013/10/7 Sanne Grinovero
>>
>> Hi Gunnar,
>> yes we've been reviewing the Infinispan Query code and it seem that
>> what we have today if good enough for this release cycle.
>> We're keeping the issues open as the current approach can use some
>>
2013/10/7 Sanne Grinovero
> Hi Gunnar,
> yes we've been reviewing the Infinispan Query code and it seem that
> what we have today if good enough for this release cycle.
> We're keeping the issues open as the current approach can use some
> polish, but time-wise we need to make space for more exp
Hi Gunnar,
yes we've been reviewing the Infinispan Query code and it seem that
what we have today if good enough for this release cycle.
We're keeping the issues open as the current approach can use some
polish, but time-wise we need to make space for more experimentation.
Sanne
On 7 October 201
Sanne,
Is there any news on where we stand with this?
I saw you discussed and moved some issues to HSEARCH 5; Does that mean we
have everything in place now for the ISPN use case? I'd have assumed at
least making the OBJECT_CLASS (HSEARCH-1402) field user-writable would be
needed for restricting
2013/10/2 Emmanuel Bernard
> But then the JSON binding technology should be responsible for the
> property anme conversion too, right? After all that is the layer that
> does this change.
>
Yes, the question then is how the layer could do the name change. It could
plug in an implementation of sa
11 matches
Mail list logo
