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
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
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
For the Hibernate Search case I could imagine to implement Steve's second
pull
approach. Search already defines an interface SearchConfiguration which
delegates the
access to the underlying Configuration properties. It should be easy to
implement some
sort of journaling to keep track which pr
The 'know in advance' approach is exactly what I was trying to avoid. I guess
that is another option I forgot on that list
It's not the I want to implement (way too tedious).
-- Sent from my Palm Pre
st...@hibernate.org
http://hibernate.orgEmmanuel Bernard wrote:
Yep.
Provided HSearch does no
Yep.
Provided HSearch does not know in advance what properties are required by its
plugins, I was wondering how that would work. That's why I asked Hardy for an
implementation example as he seemed to have understood.
On 1 févr. 2010, at 20:52, Steve Ebersole wrote:
> For Search afaict as you me
That's a separate concern if I understand you correctly.
If I summarize, you want to be able to tell core to initialize one instance of
a listener across a set of events provided the listener implements all the
required interfaces.
On 2 févr. 2010, at 00:27, Sanne Grinovero wrote:
> Didn't fol
Didn't follow the full discussion, but this looks like a good moment
to rise a flag
about HSEARCH-314: I'm still not sure if this bug is real or not,
but the ContextHolder could now be removed altogether, removing any
doubt about memory leaks:
as core registers the listener by reflection if Search
For Search afaict as you mentioned listeners will be the touchpoint
here. So it depends on what is accessible to the listeners.
At some point this just needs to be a best effort.
On Mon, 2010-02-01 at 18:42 +0100, Emmanuel Bernard wrote:
> Hardy,
> How would it work for say a DirectoryProvide
Hardy,
How would it work for say a DirectoryProvider in Hibernate search (which is a
plugin of HSearch which itself is a plugin of Core in a way - listener).
Remember we have the hibernate.search.default.[customproperty] category and the
hibernate.search.[indexname].[customproperty] category. Wh
The pull approach via an additional PropertyConsumer interface works for
me.
It seems to be a good trade-off. Least invasive while still getting some
order
into the properties.
--Hardy
On Mon, 01 Feb 2010 12:14:02 -0300, Steve Ebersole
wrote:
> On Mon, 2010-02-01 at 09:49 +0100, Emmanuel
On Mon, 2010-02-01 at 09:49 +0100, Emmanuel Bernard wrote:
> Also "plugins" can make use of the general availability of properties.
> For example Hibernate Search reads everything under hibernate.search (and
> it's not a limited set of property names). Likewise, HSearch extensions can
> use whate
Also "plugins" can make use of the general availability of properties.
For example Hibernate Search reads everything under hibernate.search (and it's
not a limited set of property names). Likewise, HSearch extensions can use
whatever property name they want to configure say the custom backend or
On Mon, 2010-01-25 at 10:12 +0100, Emmanuel Bernard wrote:
> This approach probably works fine for EM but EMF's settings have to be read
> at configuration time as they influence each other in a non trivial way. They
> are basically part of the state machine used to retrieve the list of mappings
On 25 janv. 2010, at 16:20, Steve Ebersole wrote:
> On Mon, 2010-01-25 at 10:12 +0100, Emmanuel Bernard wrote:
>
>> The "historical" setting repository for HEM is HibernatePersistence. Are we
>> deprecating it?
> I don't like deprecating stuff that has not been available yet in a
> non-ga relea
On Mon, 25 Jan 2010 06:12:55 -0300, Emmanuel Bernard
wrote:
>> We've added others in the new org.hibernate.ejb.AvailableSettings. This
>> is a mix of JPA defined settings plus some additional
>> Hibernate-EM-specific settings. I like the idea of
>> org.hibernate.ejb.AvailableSettings specifi
On Mon, 2010-01-25 at 10:12 +0100, Emmanuel Bernard wrote:
> The "historical" setting repository for HEM is HibernatePersistence. Are we
> deprecating it?
I don't like deprecating stuff that has not been available yet in a
non-ga release. Those fields are new to 3.5 and as such have only been
in
On 25 janv. 2010, at 02:27, Steve Ebersole wrote:
> There have been a few discussions on IRC about handling getProperties()
> & setProperty(..) handling in regards to the EMF and EM. I wanted to
> expand this discussion here so that:
> 1) we get a broader audence/participation;
> 2) we get a rec
26 matches
Mail list logo
