On Wed, 03 Feb 2010 16:10:39 -0300, Steve Ebersole
wrote:
> Nope. I gave up after that. I had the far more pressing jpa feature of
> "load an entity by another entity's id" to implement :D
Yeah I know what you mean, implementing the right property access type for
the
meta model generator i
Nope. I gave up after that. I had the far more pressing jpa feature of
"load an entity by another entity's id" to implement :D
If you can work that out, that would be an alternative as well.
Obviously not invasive at all.
On Wed, 2010-02-03 at 16:02 -0300, Hardy Ferentschik wrote:
> Ahh, I was
Ahh, I was wondering why you did not suggest sub-classing in your approach.
Funny that you say that all properties got pulled then. Any ideas what the
issue was?
--Hardy
On Wed, 03 Feb 2010 15:56:02 -0300, Steve Ebersole
wrote:
> Word of warning. I actually tried that :)
>
> It ended up b
Word of warning. I actually tried that :)
It ended up being all the properties. Something was pulling them all.
I tried a sublass+delegate approach (I also had trouble getting the
"default properties" to work with just straight subclassing).
FYI...
On Wed, 2010-02-03 at 15:50 -0300, Hardy Fer
I believe Steve is on the right track. As he is saying
http://pastebin.com/m6add9d4b
describes the "second pull" approach which he have been talking about in
one of the earlier
mails. This is very similar to what I had in mind as well, except I
thought about sub-classing
java.util.Properties.
I specifically said I did not want to "consolidate the constants in a
single place". Not in terms of this anyway. Because we will not know
them all ahead of time. Again, I don't see the difference between what
you mention and what would be needed for caching.
Emmanuel was asking specifically ab
Hi,
I would like to warn you about a blocking (from my point of view)
issue in Hibernate 3.5 (JIRA issue :
http://opensource.atlassian.com/projects/hibernate/browse/HHH-4864).
Dispatching entities is not supported out of the box by Hibernate/JPA,
but with a small tweak commonly used
(http://ancie
sorry I didn't understand what the purpose is, I just wanted to warn
that Search needs to read all keys, and doesn't know the exact names
beforehand.
Consolidating the constants in a single place looks like a good thing,
just wanted to check you aren't going to hide the other properties for
now. I
First, this is not the option I suggest for now. It's pretty invasive
change
Well exposing the full set of properties sort of defeats the entire
purpose no?
On Wed, 2010-02-03 at 14:42 +0100, Sanne Grinovero wrote:
> Hi Steve,
> please expose in some way the fullPropertySet too, as Search needs
Hi Steve,
please expose in some way the fullPropertySet too, as Search needs to
be able to get a list of all defined keys, for example it reads
options like
hibernate .search.Animals.batch.merge_factor = 20
or
hibernate .search.Animals.5.batch.merge_factor = 30
Where Animals is the name of an ind
Here is the basic idea: http://pastebin.com/m6add9d4b
Rather than passing around Properties, we'd pass somethign like that
around. Then we'd use its "getConsumedProperties".
On Wed, 2010-02-03 at 10:05 +0100, Emmanuel Bernard wrote:
> That's the point Hardy, the list of consumed properties is n
I don't care about who auto-registers it, Annotations is fine, core
will probably do too; I just ask to make sure it's instantiated and
initialized only once and then registered to each event using the same
FullTextIndexEventListener instance.
When using org.hibernate.search.event.EventListenerReg
So what you want is essentially to move the registering code from annotations
to core, right?
On 2 févr. 2010, at 14:34, Sanne Grinovero wrote:
> right it's a separate concern, so I'll change the subject, but it
> would still be very nice to change this before the release of
> Hiberante Core 3.5
That's the point Hardy, the list of consumed properties is not known in advance
in Hibernate search. Or is the plan get core pass all the raw Properties and
HSearch return the list of properties it really wants? In which case it will
return all of them to implement our current approach.
I guess
14 matches
Mail list logo
