On Aug 30, 2011, at 11:51 AM, Zach Kurey wrote:
>
> On Aug 30, 2011, at 11:40 AM, Sanne Grinovero wrote:
>
>> Yes I understood that was your suggestions; but I think that using
>> @IndexEmbedded(depth=0, {IndexPath1, IndexPath2})
>> would get you exactly what you wanted?
>
> Ahh gotcha. I mis
On Aug 30, 2011, at 11:40 AM, Sanne Grinovero wrote:
> Yes I understood that was your suggestions; but I think that using
> @IndexEmbedded(depth=0, {IndexPath1, IndexPath2})
> would get you exactly what you wanted?
Ahh gotcha. I misunderstood. Yes that works for me.
>
> Just that I can still
2011/8/30 Zach Kurey :
[...]
>
> Maybe there is some confusion about what I was proposing. The idea is not
> to have 'additional paths'. Instead the intent is to explicitly state that
> hibernate search should index 'only these paths' from the property it is
> declared on onward. Which is why I
On Aug 30, 2011, at 10:47 AM, Sanne Grinovero wrote:
> I'm not 100% convinced but please go ahead and create a JIRA. There
> are definitely good improvements to take out of this thread, we can
> flesh out the details on JIRA or after a proof of concept patch.
>
> My doubts is that I don't like a
> It sounds like @IndexPaths is acceptable to everyone. Sanne, you seemed to
> be the most concerned from your last response about the direction this was
> going. Any more thoughts here or does it sound reasonable to move this
> proposal/request into a JIRA ticket at this point?
Hi Zach,
I'm
On Aug 26, 2011, at 1:14 AM, Hardy Ferentschik wrote:
>> Option 1: Explicit inclusion only
>> @IndexPaths(
>> paths={
>> @IndexPath("a.b.c"),
>> @IndexPath("d.e")
>> }
>> )
>> private SomeType type;
>
> @IndexPath allows for further extension, but I could live with s
> @IndexedEmbedded(depth = 1, paths={"livingAddress.countryCode",
> "bornPlace.countryCode"})
> private Person ownedBy
I think leaving out the excludes is a good idea and specifying paths as
strings seems to be e easier option. However, I still would make it a new
annotation (@IndexPaths) or a
> Option 1: Explicit inclusion only
> @IndexPaths(
>paths={
>@IndexPath("a.b.c"),
>@IndexPath("d.e")
>}
> )
> private SomeType type;
@IndexPath allows for further extension, but I could live with simple
strings as well.
> I would be ecstatic if just @IndexP
> While I'm obviously not so excited about the exclusions idea, maybe
> I'm overseeing a very useful case; is there a compelling reason to
> want that, enough to justify the added complexity? I'm not so much
> concerned about our code complexity (which might be an issue too) but
> more about the th
I think the original proposal was great, but also that we're now
pushing it to accomplish too much.
This feature as the potential to be *brilliant* but it must be
striking simple to both understand and use.
So what I like of the original concept, is that people using it will
focus on what they nee
On Aug 25, 2011, at 9:31 AM, Hardy Ferentschik wrote:
> It still conflicts with the actual default value of depth and that there is
> no explicit way to say that it is ignored. I don't think "it seems clear"
> is a good enough reason.
That's reasonable. If everything is left in IndexEmbedded yo
On Thu, 25 Aug 2011 17:47:30 +0200, Zach Kurey
wrote:
>
> On Aug 25, 2011, at 2:28 AM, Hardy Ferentschik wrote:
>
>> Or just 'include' and 'exclude'.
>> I feel we are becoming overly verbose in the API design (which is
>> besides
>> this
>> particular issue)
>
> That doesn't seem clear to me.
On Aug 25, 2011, at 2:28 AM, Hardy Ferentschik wrote:
> Or just 'include' and 'exclude'.
> I feel we are becoming overly verbose in the API design (which is besides
> this
> particular issue)
That doesn't seem clear to me. If its just include/exclude, what exactly is
being included/excluded?
On 25 août 2011, at 11:28, Hardy Ferentschik wrote:
> My experience that is is not a good idea to change implicitly
> ignore default values. In this case I would rather see an additional
> enum parameter which allows the user to explicitly select the embedding
> mode (BY_DEPTH, BY_PATH) or maybe
Comments inline:
>> This complicates things. First of all it means that the "subPaths"
>> property should now be named "includeSubPaths" instead, as opposing to
>> "excludeSubPaths".
>
> Yes, if 'excludeSubPaths' is provided, then 'subPaths' should be renamed
> to 'includeSubPaths', for cleanlin
On Aug 24, 2011, at 8:26 AM, Sanne Grinovero wrote:
> This complicates things. First of all it means that the "subPaths"
> property should now be named "includeSubPaths" instead, as opposing to
> "excludeSubPaths".
Yes, if 'excludeSubPaths' is provided, then 'subPaths' should be renamed to
'in
2011/8/22 Zach Kurey :
> Hi,
>
> I was the poster on the forum that triggered this conversation. Sanne
> suggested I jump onto the dev mailing list for this and future suggestions,
> so here I am. I'm a developer in the San Francisco bay area. I've been
> using hibernate search for about a ye
Hi,
I was the poster on the forum that triggered this conversation. Sanne
suggested I jump onto the dev mailing list for this and future suggestions, so
here I am. I'm a developer in the San Francisco bay area. I've been using
hibernate search for about a year on a project I've been working
On Mon, 22 Aug 2011 14:26:35 +0200, Emmanuel Bernard
wrote:
>
> On 22 août 2011, at 14:07, Hardy Ferentschik wrote:
>
>> Not sure if I like the surrogate Document idea. Maybe we can get rid of
>> exposing any type
>> of "Document". The bridge could just return a Field(able).
>
> You can't do th
On 22 août 2011, at 14:07, Hardy Ferentschik wrote:
> Not sure if I like the surrogate Document idea. Maybe we can get rid of
> exposing any type
> of "Document". The bridge could just return a Field(able).
You can't do that. At least you need a (conceptual) Set.
__
On Mon, 22 Aug 2011 13:20:43 +0200, Sanne Grinovero
wrote:
> 2011/8/22 Emmanuel Bernard :
>> That's an interesting idea.
>> It has some limitations like the inability to cover class level bridges
>> but that might not be too bad.
>
> Right. I think we should support entities having class leve
On Mon, 22 Aug 2011 12:58:00 +0200, Sanne Grinovero
wrote:
> 2011/8/19 Hardy Ferentschik :
>> Hi,
>>
>> I am not sure I understand the suggested path parameter. Taking the
>> example from the forum:
>>
>>
>> class A{
>>@IndexEmbedded(
>>paths={"d.one", "d.two"}
>> )
>>privat
2011/8/22 Emmanuel Bernard :
> That's an interesting idea.
> It has some limitations like the inability to cover class level bridges but
> that might not be too bad.
Right. I think we should support entities having class level bridges
as @IndexedEmbedded, by prefixing whatever they want to add to
2011/8/19 Hardy Ferentschik :
> Hi,
>
> I am not sure I understand the suggested path parameter. Taking the
> example from the forum:
>
>
> class A{
> @IndexEmbedded(
> paths={"d.one", "d.two"}
> )
> private C see;
> }
>
> class B{
> @IndexEmbedded(
> paths={"foo", "d.two
That's an interesting idea.
It has some limitations like the inability to cover class level bridges but
that might not be too bad.
On 19 août 2011, at 11:07, Sanne Grinovero wrote:
> Hi all,
> I just noticed this proposal on the forum:
> https://forum.hibernate.org/viewtopic.php?f=9&t=1012303
Hi,
I am not sure I understand the suggested path parameter. Taking the
example from the forum:
class A{
@IndexEmbedded(
paths={"d.one", "d.two"}
)
private C see;
}
class B{
@IndexEmbedded(
paths={"foo", "d.two"}
)
private C see;
}
class C{
@Index
Hi all,
I just noticed this proposal on the forum:
https://forum.hibernate.org/viewtopic.php?f=9&t=1012303
I think it's very reasonable, as people don't usually care for the
depth but for the fields they can or can not search.
In addition to a better API, for the sake of the Query Parser
somethin
27 matches
Mail list logo
