On 27 May 2014 20:55, Hardy Ferentschik wrote:
>
>>> So what is your take on this then? Leave as is and keep the fact that the
>>> default depth value changes its default value depending
>>> on whether or not includePaths is used? That would be option
>>>
>>> #3 Keep status quo for value of depth
>> So what is your take on this then? Leave as is and keep the fact that the
>> default depth value changes its default value depending
>> on whether or not includePaths is used? That would be option
>>
>> #3 Keep status quo for value of depth parameter
>>
>> I raised the concern that the simp
On 27 May 2014, at 12:29, Hardy Ferentschik wrote:
> Thanks for the input. Comments inline.
>
> On 27 Jan 2014, at 12:01, Emmanuel Bernard wrote:
>
>>
>> On 06 May 2014, at 21:43, Hardy Ferentschik wrote:
>>
>>> Where are we at in this discussion?
>>>
>>> I think we basically have to main
On 29 Apr 2014, at 15:09, Sanne Grinovero wrote:
> I'd actually like to propose to change the depth default to zero, and
> since includePath also defaults to an empty list, we'd be logging a
> warning as the @IndexedEmbedded annotation would have no effect.
>
>
>> I also find it not intuitive
Thanks for the input. Comments inline.
On 27 Jan 2014, at 12:01, Emmanuel Bernard wrote:
>
> On 06 May 2014, at 21:43, Hardy Ferentschik wrote:
>
>> Where are we at in this discussion?
>>
>> I think we basically have to main proposals.
>>
>> #1 Don’t include the embedded id per default. If
On 29 Apr 2014, at 20:43, Hardy Ferentschik wrote:
> On 29 Jan 2014, at 15:24, Sanne Grinovero wrote:
>
But this forces you to list all fields to include explicitly in case you
want the id added, but otherwise are happy
to just use the default @IndexedEmbedded.
>>>
>>> I think
On 06 May 2014, at 21:43, Hardy Ferentschik wrote:
> Where are we at in this discussion?
>
> I think we basically have to main proposals.
>
> #1 Don’t include the embedded id per default. If @IndexEmbedded is used via
> the depth parameter there is no way to include the embedded id.
> In
Hi,
On Tue, May 6, 2014 at 9:43 PM, Hardy Ferentschik wrote:
> I think I favour #2 atm, since it seems more symmetric.
I'm also in favour of #2.
> On top of this we seem to agree that it is a good idea to set the default
> depth value of @IndexedEmbedded to 0. This avoids the change in default
Where are we at in this discussion?
I think we basically have to main proposals.
#1 Don’t include the embedded id per default. If @IndexEmbedded is used via the
depth parameter there is no way to include the embedded id.
In order to include the id you would need to use includePaths. depth a
> So it has been an explicit choice at some point of time.
>
>> - API wise it's much more complex to express the request-for-removal
>> than to simply add it to includePath when needed
>
> The question is also about a consistent behaviour across all use cases. Sure,
> we can add the id via the
On 29 Jan 2014, at 15:24, Sanne Grinovero wrote:
>>> But this forces you to list all fields to include explicitly in case you
>>> want the id added, but otherwise are happy
>>> to just use the default @IndexedEmbedded.
>>
>> I think we should keep the id with the default @IndexedEmbedded. It
>
>>> Remember _includePath_ is additive to fields otherwise included via
>>> @IndexedEmbedded _depth_, so it fits nicely for this role:
>>
>> Is that really true? AFAIK the includePath attribute changes the behaviour
>> of the depth attribute.
>> Depth is ‘0’ per default if ‘includePath’ is used.
On 29 April 2014 13:49, Guillaume Smet wrote:
> Hi,
>
> On Tue, Apr 29, 2014 at 1:45 PM, Hardy Ferentschik
> wrote:
>>> Yes I mean we could never include it by default, and allow the
>>> "includePath" to be the (only) way to include things.
>>
>> But this forces you to list all fields to include
On 29 April 2014 12:45, Hardy Ferentschik wrote:
>
Question: would we still interpret the literal "id" as a keyword
pointing to whatever getter is the primary key of the embedded object?
>>>
>>> Why still? We don’t do this at the moment afaict. Our examples and tests
>>> just use ‘id’
>
Hi,
On Tue, Apr 29, 2014 at 1:45 PM, Hardy Ferentschik wrote:
>> Yes I mean we could never include it by default, and allow the
>> "includePath" to be the (only) way to include things.
>
> But this forces you to list all fields to include explicitly in case you want
> the id added, but otherwise
>>> Question: would we still interpret the literal "id" as a keyword
>>> pointing to whatever getter is the primary key of the embedded object?
>>
>> Why still? We don’t do this at the moment afaict. Our examples and tests
>> just use ‘id’
>> all the time.
>
> Right I got confused. I thought fo
On 29 April 2014 11:28, Hardy Ferentschik wrote:
>
> On 29 Jan 2014, at 00:14, Sanne Grinovero wrote:
>
>> I'd avoid a new configuration element.
>
> +1 Sure, that would be best.
>
>> I think we should strive at keeping the index small by default unless
>> there is a strong usability penalty, and
On 29 Jan 2014, at 00:14, Sanne Grinovero wrote:
> I'd avoid a new configuration element.
+1 Sure, that would be best.
> I think we should strive at keeping the index small by default unless
> there is a strong usability penalty, and I don't think this is a big
> one.
I agree. I don’t think t
Hi Hardy,
I'd avoid a new configuration element.
I think we should strive at keeping the index small by default unless
there is a strong usability penalty, and I don't think this is a big
one.
Some power users pointed out that there are use cases in which having
the _id_ field of embedded relation
Hi,
I started to look at HSEARCH-1494 [1] which deals with an unexpected exception
is thrown when @IndexedEmbedded is used.
Easiest to explain with an example:
@Entity
@Indexed
public class A {
@Id
@GeneratedValue
private long id;
@OneToOne
@IndexedEmbedd
20 matches
Mail list logo
