Re: [hibernate-dev] Building a SessionFactory
I was getting lost trying to follow this email thread, IRC logs, private conversations, and the confusion due to a typo, so I created a gist page (https://gist.github.com/943347). I've tried to summarizes the alternatives and added a couple of my own. I've also included some open questions that need to be resolved. I've omitted stuff from when we were confused by the typo. Maybe it confuses things even more to put info in yet another place (gist), but I was getting so confused, it's at least helped me to get things straight. - Original Message - From: "Steve Ebersole" To: "Emmanuel Bernard" Cc: hibernate-dev@lists.jboss.org Sent: Tuesday, April 26, 2011 11:47:12 AM Subject: Re: [hibernate-dev] Building a SessionFactory John just pointed out a type here that caused everyone some confusion. I apologize. MetadataSources sources = new MetadataSources(...) ... .getMetadataBuilder() .setNamingStrategy( ... ) .buildMetadata(); should really read: Metadata metadata = new MetadataSources(...) ... .getMetadataBuilder() .setNamingStrategy( ... ) .buildMetadata(); On 04/26/2011 11:43 AM, Steve Ebersole wrote: > Builder is a generic term. The specific function served here is that of > a set of sources for metadata. > > The same does not hold for ServiceRegistryBuilder. It does not hold a > singular type of information. In fact initially I shied away from the > name ServiceRegistryBuilder because of its genericness. But in the end > decided to use it because it would be familiar to developers. > > On 04/26/2011 11:05 AM, Emmanuel Bernard wrote: >> I think we can converge by using the following approach. >> https://gist.github.com/942450 >> >> Check the meeting logs, we have discussed the idea further. >> >> BTW it occurred to me that MetadataSources is more a builder than >> anything else, should it be renamed to align with the service registry >> approach? >> >> On 22 avr. 2011, at 20:43, Steve Ebersole wrote: >> >>> I do not disagree, especially about the clutter. I had two related >>> concerns with that this approach though: >>> 1) minor, but this thing is then no longer just collecting the >>> sources of metadata which is what a MetadataSources is. >>> 2) this is no longer a "directed API" at all. What do I mean by that? >>> Well: >>> >>> MetadataSources sources = new MetadataSources(...); >>> sources.setNamingStrategy( strategy1 ); >>> sources.addResource( "some/resource.xml" ); >>> sources.setNamingStrategy( strategy2 ); >>> sources.addResource( "some/resource2.xml" ); >>> >>> We are not "directing" the users to the correct usage of the API by >>> the design of the API itself. >>> >>> >>> Here is another option: >>> MetadataSources sources = new MetadataSources(...) >>> ... >>> .getMetadataBuilder() >>> .setNamingStrategy( ... ) >>> .buildMetadata(); >>> >>> Now the naming strategy is associated with this "metadata builder" >>> which is more semantically correct. But this is a bit verbose for >>> today since I can only think of naming strategy as falling into this >>> bucket. >>> >>> >>> On 04/22/2011 03:37 AM, Emmanuel Bernard wrote: My preference would go to a MetadataSources#setMetadata(NamingStrategy) My fear is that more functions could be needed overtime and make the constructor or the buildMetadata signature cluttered and less readable. On 21 avr. 2011, at 15:08, Steve Ebersole wrote: > NamingStrategy is not a service. It is solely a function of > building the metadata. > > Currently, again, I have this set up via ctor param passing: > > new MetadataSources( reg, new MyNamingStrategy() ) > > Really its not logically part of the source, its needed during the > transition from source->metadata, so an alternative I have been > contemplating is: > > new MetadataSources( reg ).buildMetadata( new MyNamingStrategy() ) > > I am open to other suggestions. I really am trying to keep in mind > the scope in which stuff is needed/useful/valid. > > > On 04/21/2011 03:11 AM, Emmanuel Bernard wrote: >> >> On 21 avr. 2011, at 05:43, Steve Ebersole wrote: >> >>> I think this new API for creating a SessionFactory is starting to >>> firm >>> up, so I wanted to put out another call for feedback before we >>> get too >>> close to Alpha3. So at a high level there are 2 pieces of >>> information >>> needed to build the SessionFactory: the ServiceRegistry and the >>> Metadata. >>> >>> ~ >>> >>> The ServiceRegistry is built through a ServiceRegistryBuilder >>> (this is a >>> slight recent change) >>> >>> Map config = ...; >>> ServiceRegistry serviceRegistry = new ServiceRegistryBuilder( >>> config ) >>> ... >>> .buildServiceRegistry(); >>> >>> The "..." allows you to add service instances and servi
Re: [hibernate-dev] Meeting logs since Max's bot failed us
just to conclude this one - I had the bot configured to login before nickserv responded; now it waits and thus it should get into hibernate-dev without problems next time something causes a network outage ;) /max On Apr 26, 2011, at 20:53, Max Rydahl Andersen wrote: > >> jpav: no one started the bot yet >> emmanuel: #startmeeting >> jpav: I don't think the bot is even running >> emmanuel: maxandersen: BOT >> emmanuel: Ok nevermind let's start > > > sorry for that one - not sure why but jbott was logged into all channels but > somehow either got rejected or kicked of #hibernate-dev. > > its back in. > > /max > http://about.me/maxandersen > > > > > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev /max http://about.me/maxandersen ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Hibernate Search 3.5 or 4
Updated the wiki: http://community.jboss.org/docs/DOC-16743 I'll highlight here some previously unmentioned details: - Service instances (being discussed) * for the public extensions points sometimes it's useful to pass instances instead of mere classnames to a SearchConfiguration o Infinispan Query would love it to pass a self-built Directory factory so that Search could use that to store indexes on the same Infinispan instance (instead of starting a second cluster). - about the less-static mapping: I've thought that the tricky part is going to be matching the proper analyzer in the backend - mentioned that. - Added a "(being discussed)" flag to what I wasn't still sure was approved by Emmanuel and Hardy as I had no positive feedback yet. (I might have forgot others to cheat you..) Cheers, Sanne 2011/4/26 Sanne Grinovero : > some late answers: > > 2011/4/21 Emmanuel Bernard : >> OK, if we want to do all of this we will hate to start very quickly. In >> fairness, I'm not sure we can even do all of this so let's make sure these >> are prioritized accordingly. >> I could not find the expected deadlines for AS 7 / Cre 4 but we are probably >> talking about June here: ie very soon. >> >> Some more comments inline. >> >> On 20 avr. 2011, at 10:21, Sanne Grinovero wrote: >> >>> Hi, >>> About changing contracts, we don't get this chance very often so we >>> should make sure we don't miss any. >>> I have some favourites I'd like to discuss: >>> >>> - work list sent to backend >>> -- As you know Lucene dropped all guarantees about serializability, >>> supporting stuff like JMS requires a format change; especially the >>> NumericField is not working right now as it was never serializable >>> (HSEARCH-681) >> >> +1 >> >>> -- Lucene is being more flexible about updates, I don't think we >>> should keep remapping an "update" operation as a delete+add operation, >>> but transmit the "update operation" and let the backend figure out >>> what's best. >> >> I guess we could do that. we need to make sure collections "updates" play >> well in that mix. > > the urgent bit of the proposal is to add an "update" operation as a > supported verb. there's no need to convert the collections updates > from using a "delete+add" soon, I just mean to make it possible to > later improve on this so that the contract allows it. > >>> - DirectoryProvider >>> -- make a "DirectoryManager" instead, which is able to provide >>> factories for both IndexReader an IndexWriters >>> -- add utility methods like "getName()", wish I had that in some >>> cases to provide better error messages. This leads me to think that >>> instead of trying to foresee all needed methods, the extension point >>> should not be the DirectoryManager interface directly, but have people >>> plug in different aspects. >> >> That might be better also since it reduces the scope, it's easier to design >> the contract. >> >>> -- this is needed to support both Instantiated indexes and to make >>> good use of all new so called "Near-Real-Time" Lucene improvements. >>> >>> - ReaderProvider >>> -- (assuming should a thing would still exist): I think it would be >>> very nice if the responsibility of such a provider would be to provide >>> the IndexReader for a single index. currently it has to provide a >>> "multiReader" on each different index, making some implementations >>> very tricky (seems I got it right in SharingBufferReaderProvider, but >>> I recently had some other interesting ideas which revelaed quite >>> dounting after a draft: take responsibility of the FieldCache expiry >>> directly, to be able to plug different cache implementations, we >>> control the lifecycle and we can be much smarter). >> >> ok, we might be able to do that in a 4.1 if need be. > > right, no need to make the new FieldCache integration, but we'd need > to change the ReaderProvider API to work on a single index. > >> >>> >>> - backends and workers >>> -- I'd like to make it possible to configure different backends per >>> index. currently a backend is global, while in some cases (extreme) it >>> would have been hand to configure even single shards to different >>> backends. So really a backend should be something coupled to the >>> "DirectoryManager" mentioned before. Question is, at what level is >>> sharding going to work, it could work as a multiplexing >>> DirectoryManager. >> >> Can you remind us the use case behind heterogeneous backends. There was one >> but I forgot. > > it's mostly about performance details, the possibility to have > different entities configured with different requirements: so for > example one entity might have large indexes and use the rsync copy > algorithm via the master/slave index providers configured to synch the > index once per hour or day using async JMS as backend, while another > entity requires transactional synchronization over the cluster and so > might need an in sync JMS with the Infinispan directoryprovider. > Currently peo
Re: [hibernate-dev] Meeting logs since Max's bot failed us
> jpav: no one started the bot yet > emmanuel: #startmeeting > jpav: I don't think the bot is even running > emmanuel: maxandersen: BOT > emmanuel: Ok nevermind let's start sorry for that one - not sure why but jbott was logged into all channels but somehow either got rejected or kicked of #hibernate-dev. its back in. /max http://about.me/maxandersen ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Building a SessionFactory
John just pointed out a type here that caused everyone some confusion. I apologize. MetadataSources sources = new MetadataSources(...) ... .getMetadataBuilder() .setNamingStrategy( ... ) .buildMetadata(); should really read: Metadata metadata = new MetadataSources(...) ... .getMetadataBuilder() .setNamingStrategy( ... ) .buildMetadata(); On 04/26/2011 11:43 AM, Steve Ebersole wrote: > Builder is a generic term. The specific function served here is that of > a set of sources for metadata. > > The same does not hold for ServiceRegistryBuilder. It does not hold a > singular type of information. In fact initially I shied away from the > name ServiceRegistryBuilder because of its genericness. But in the end > decided to use it because it would be familiar to developers. > > On 04/26/2011 11:05 AM, Emmanuel Bernard wrote: >> I think we can converge by using the following approach. >> https://gist.github.com/942450 >> >> Check the meeting logs, we have discussed the idea further. >> >> BTW it occurred to me that MetadataSources is more a builder than >> anything else, should it be renamed to align with the service registry >> approach? >> >> On 22 avr. 2011, at 20:43, Steve Ebersole wrote: >> >>> I do not disagree, especially about the clutter. I had two related >>> concerns with that this approach though: >>> 1) minor, but this thing is then no longer just collecting the >>> sources of metadata which is what a MetadataSources is. >>> 2) this is no longer a "directed API" at all. What do I mean by that? >>> Well: >>> >>> MetadataSources sources = new MetadataSources(...); >>> sources.setNamingStrategy( strategy1 ); >>> sources.addResource( "some/resource.xml" ); >>> sources.setNamingStrategy( strategy2 ); >>> sources.addResource( "some/resource2.xml" ); >>> >>> We are not "directing" the users to the correct usage of the API by >>> the design of the API itself. >>> >>> >>> Here is another option: >>> MetadataSources sources = new MetadataSources(...) >>> ... >>> .getMetadataBuilder() >>> .setNamingStrategy( ... ) >>> .buildMetadata(); >>> >>> Now the naming strategy is associated with this "metadata builder" >>> which is more semantically correct. But this is a bit verbose for >>> today since I can only think of naming strategy as falling into this >>> bucket. >>> >>> >>> On 04/22/2011 03:37 AM, Emmanuel Bernard wrote: My preference would go to a MetadataSources#setMetadata(NamingStrategy) My fear is that more functions could be needed overtime and make the constructor or the buildMetadata signature cluttered and less readable. On 21 avr. 2011, at 15:08, Steve Ebersole wrote: > NamingStrategy is not a service. It is solely a function of > building the metadata. > > Currently, again, I have this set up via ctor param passing: > > new MetadataSources( reg, new MyNamingStrategy() ) > > Really its not logically part of the source, its needed during the > transition from source->metadata, so an alternative I have been > contemplating is: > > new MetadataSources( reg ).buildMetadata( new MyNamingStrategy() ) > > I am open to other suggestions. I really am trying to keep in mind > the scope in which stuff is needed/useful/valid. > > > On 04/21/2011 03:11 AM, Emmanuel Bernard wrote: >> >> On 21 avr. 2011, at 05:43, Steve Ebersole wrote: >> >>> I think this new API for creating a SessionFactory is starting to >>> firm >>> up, so I wanted to put out another call for feedback before we >>> get too >>> close to Alpha3. So at a high level there are 2 pieces of >>> information >>> needed to build the SessionFactory: the ServiceRegistry and the >>> Metadata. >>> >>> ~ >>> >>> The ServiceRegistry is built through a ServiceRegistryBuilder >>> (this is a >>> slight recent change) >>> >>> Map config = ...; >>> ServiceRegistry serviceRegistry = new ServiceRegistryBuilder( >>> config ) >>> ... >>> .buildServiceRegistry(); >>> >>> The "..." allows you to add service instances and service >>> initiators. >>> Currently any (map of) configuration values is passed in the >>> constructor. I can be convinced to allow adding/setting of config >>> values as well, if everyone has a preference for that approach: >>> >>> Map config = ...; >>> ServiceRegistry serviceRegistry = new ServiceRegistryBuilder() >>> .setConfigurationData( config ) >>> .setOption( Environment.SHOW_SQL, >>> true ) >>> ... >>> .buildServiceRegistry(); >>> >>> Not sure the best method names there, to be honest which is why I >>> opted >>> for passing them to ctor. >> >> Is that a Map or something a bit more refined? >> >> Regardless of the map being passed to the ctor, I'd think
Re: [hibernate-dev] Integrator and retrieving objects
To clarify, FullTextSession is stateless besides holding a pointer to the
Session(Implementor). so we would be fine by creating a new FullTextSession
object every time as() is called.
On 26 avr. 2011, at 19:47, Sanne Grinovero wrote:
> 2011/4/26 Steve Ebersole :
>> as(...) is on Session though. What I am talking about is what happens when
>> they *somehow* get a normal Session and call session.as(
>> FullTextSession.class ) ?
>>
>> e.g.
>>
>> fullTextSession.getSessionFactory()
>>.openSession()
>>.as( FullTextSession.class );
>>
>> Now what?
>
> Let's assume we also have a service called "SessionAsHandler", which
> contains a map of factories, where the key is the target class (like
> FullTextSession.class )
> The "as" implementation could look into the SessionAsHandler, perform then
>
> get(FullTextSession.class).create( this );
>
> where:
> - this is the current SessionImplementor
> - the return type is a FullTextSession instance
>
> And when the SearchService is created, it configures this additional
> service as well to handle the new type.
>
>>
>> I guess this really gets to the intent of as(...).
>>
>> Like I can see the usefulness of "light binding" the notions of a Session
>> and a FullTextSession (not so sure wrt AuditReader, I'd have to understand
>> the relation there a little better) such that the following is valid:
>>
>> normalHibernateSessionFactory.openSession()
>>.as( FullTextSession.class )
>>.()
>>
>> But there are a lot of implications there. Like we need to be able to make
>> the SessionFactory aware of the other "sub factories" and track the "sub
>> sessions" per Session (lazily!).
>
> I'm not sure I follow here about tracking and lazily. Why should you
> track the "sub sessions"? In case of Search, the
> FullTextSession.close() will close it's own resources and close the
> underlying Session as well; I think it's enough for the SessionFactory
> to track the standard Session and doesn't need to worry about more
> resources.
>
>>
>> Heck, I would *love* to see:
>> normalHibernateSessionFactory.openSession()
>>.as( EntityManager.class )
>>...
>
> but then the EntityManager would be able to behave according to JPA
> spec? I'm referring for example to the different kind of
> eventlisteners needed, as Emmanuel mentioned at the meeting today.
> Still this example is so cool, it could be worthwhile to reconsider
> some of the meeting thoughts.
> Would you expect the EntityManager to be closed if I closed the
> Session? And flush, other operations? according to which spec shall it
> behave?
>
> Cheers,
> Sanne
>
>
>> On 04/26/2011 01:31 AM, Sanne Grinovero wrote:
>>>
>>> 2011/4/25 Steve Ebersole:
Just to circle back to this (because my memory is so short)..
What did we ever decide about this, especially in regards to the *how*?
As and example, lets look at Search. Search wraps Session in a
FullTextSession. Search would register some handler with the
SessionFactory that says it knows how to handle Session.as(
FullTextSession.class ) calls. But what exactly is this handler going
to do? Unless Search maintains some global Session instance ->
FullTextSession instance... Or are you thinking the registration
happens per-Session?
>>>
>>> The entry points for Search are two:
>>> - the session *EventListener(s) (only one instance, but listening to
>>> multiple types of events)
>>> - the FullTextSession
>>>
>>> A FullTextSession needs a reference to the current session, and a
>>> reference to the SearchFactoryImplementor, which is the heavy-weight
>>> global component, similar to a SessionFactory.
>>>
>>> Currently a FullTextSession implements Session and is created from the
>>> Session it wraps using a static helper which searches for it's own
>>> PostInsertEventListener in the Session itself, from which it takes a
>>> reference to the needed SearchFactoryImplementor.
>>>
>>> I would be a nice improvement if the "as( FullTextSession.class )"
>>> implementation could retrieve the SearchFactoryImplementor from the
>>> ServiceRegistry instead.
>>>
>>> In pseudo code, the "as" implementation for search would look like
>>> something as:
>>>
>>> FullTextSession createFullTextSession() {
>>>return new FullTextSession( Session current, serviceRegistry.get(
>>> SearchFactoryImplementor.class ) );
>>> }
>>>
>>> (or even simpler if SessionImplementor makes it possible to retrieve
>>> services )
>>>
>>> Regards,
>>> Sanne
>>>
On 04/06/2011 09:28 AM, Emmanuel Bernard wrote:
>
> yes as is indeed better.
>
> On 6 avr. 2011, at 13:29, Steve Ebersole wrote:
>
>> A phrase I see a lot here is "as":
>>
>> session.as( AuditReader.class ).someEnversSpecificMethod()
>>
>> or
>>
>> session.as( FullTextSession.class )...
>>
>>
>> On 04/06/2011 06:26 AM, Adam Warski wrote:
>>>
>>
Re: [hibernate-dev] Integrator and retrieving objects
2011/4/26 Steve Ebersole :
> as(...) is on Session though. What I am talking about is what happens when
> they *somehow* get a normal Session and call session.as(
> FullTextSession.class ) ?
>
> e.g.
>
> fullTextSession.getSessionFactory()
> .openSession()
> .as( FullTextSession.class );
>
> Now what?
Let's assume we also have a service called "SessionAsHandler", which
contains a map of factories, where the key is the target class (like
FullTextSession.class )
The "as" implementation could look into the SessionAsHandler, perform then
get(FullTextSession.class).create( this );
where:
- this is the current SessionImplementor
- the return type is a FullTextSession instance
And when the SearchService is created, it configures this additional
service as well to handle the new type.
>
> I guess this really gets to the intent of as(...).
>
> Like I can see the usefulness of "light binding" the notions of a Session
> and a FullTextSession (not so sure wrt AuditReader, I'd have to understand
> the relation there a little better) such that the following is valid:
>
> normalHibernateSessionFactory.openSession()
> .as( FullTextSession.class )
> .()
>
> But there are a lot of implications there. Like we need to be able to make
> the SessionFactory aware of the other "sub factories" and track the "sub
> sessions" per Session (lazily!).
I'm not sure I follow here about tracking and lazily. Why should you
track the "sub sessions"? In case of Search, the
FullTextSession.close() will close it's own resources and close the
underlying Session as well; I think it's enough for the SessionFactory
to track the standard Session and doesn't need to worry about more
resources.
>
> Heck, I would *love* to see:
> normalHibernateSessionFactory.openSession()
> .as( EntityManager.class )
> ...
but then the EntityManager would be able to behave according to JPA
spec? I'm referring for example to the different kind of
eventlisteners needed, as Emmanuel mentioned at the meeting today.
Still this example is so cool, it could be worthwhile to reconsider
some of the meeting thoughts.
Would you expect the EntityManager to be closed if I closed the
Session? And flush, other operations? according to which spec shall it
behave?
Cheers,
Sanne
> On 04/26/2011 01:31 AM, Sanne Grinovero wrote:
>>
>> 2011/4/25 Steve Ebersole:
>>>
>>> Just to circle back to this (because my memory is so short)..
>>>
>>> What did we ever decide about this, especially in regards to the *how*?
>>>
>>> As and example, lets look at Search. Search wraps Session in a
>>> FullTextSession. Search would register some handler with the
>>> SessionFactory that says it knows how to handle Session.as(
>>> FullTextSession.class ) calls. But what exactly is this handler going
>>> to do? Unless Search maintains some global Session instance ->
>>> FullTextSession instance... Or are you thinking the registration
>>> happens per-Session?
>>
>> The entry points for Search are two:
>> - the session *EventListener(s) (only one instance, but listening to
>> multiple types of events)
>> - the FullTextSession
>>
>> A FullTextSession needs a reference to the current session, and a
>> reference to the SearchFactoryImplementor, which is the heavy-weight
>> global component, similar to a SessionFactory.
>>
>> Currently a FullTextSession implements Session and is created from the
>> Session it wraps using a static helper which searches for it's own
>> PostInsertEventListener in the Session itself, from which it takes a
>> reference to the needed SearchFactoryImplementor.
>>
>> I would be a nice improvement if the "as( FullTextSession.class )"
>> implementation could retrieve the SearchFactoryImplementor from the
>> ServiceRegistry instead.
>>
>> In pseudo code, the "as" implementation for search would look like
>> something as:
>>
>> FullTextSession createFullTextSession() {
>> return new FullTextSession( Session current, serviceRegistry.get(
>> SearchFactoryImplementor.class ) );
>> }
>>
>> (or even simpler if SessionImplementor makes it possible to retrieve
>> services )
>>
>> Regards,
>> Sanne
>>
>>>
>>>
>>> On 04/06/2011 09:28 AM, Emmanuel Bernard wrote:
yes as is indeed better.
On 6 avr. 2011, at 13:29, Steve Ebersole wrote:
> A phrase I see a lot here is "as":
>
> session.as( AuditReader.class ).someEnversSpecificMethod()
>
> or
>
> session.as( FullTextSession.class )...
>
>
> On 04/06/2011 06:26 AM, Adam Warski wrote:
>>
>> On Apr 6, 2011, at 1:20 PM, Steve Ebersole wrote:
>>
>>> The phrase 'unwrap' might be a bit misleading there because you may
>>> not be dealing with wrapped objects. But the idea itself is still
>>> solid I
>>> believe. Think of it more as a multi-directional cast
>>
>> Right, the idea sounds good; so it would be something like a
>> per-session service? :)
>> Envers could use it as well, right now
[hibernate-dev] Meeting logs since Max's bot failed us
emmanuel: hello everyone gbadner: hi emmanuel: have you guys started the meeting? jpav: you just did I think hardy: seems like it sannegrinovero: hi emmanuel, no not yet jpav: no one started the bot yet emmanuel: #startmeeting jpav: I don't think the bot is even running emmanuel: maxandersen: BOT emmanuel: Ok nevermind let's start emmanuel: someone can send his logs emmanuel: Has anyone followed the discussion around the SessionFActory API? emmanuel: The email thread between Steve and I is the latest I think emmanuel: What do you think of it? emmanuel: Thought of improvements? hardy: not from my side smarlow [~smarlow@redhat/jboss/smarlow] entered the room. (17:09:07) emmanuel: Based on the latest exchange from Steve, I thoguht of this emmanuel: https://gist.github.com/942450 emmanuel: Which I think keep the API as he wants while still avoiding the constructor trap emmanuel: OK it does not seem people ahve put thoughts on it. Have a look at what has been proposed and trya nd give some feedback to steve in the next day or two. emmanuel: Topic number 2: what to do with EJB3Configuration? emmanuel: Let me summarize, sannegrinovero: it looks like to make sense to me, but I'm not that aware of the core requirements. gbadner: yes, I like it stliu: what's the initial idea? merge it into somewhere? emmanuel: In H4, we now have a ServiceregistryBuilder building a ServiceRegistry and a MetadataSources object that creates a Metadata object >From the Metadata object you get the SessionFActory emmanuel: In H3.x, we had a Configuration object that was responsible for the role taken by ServiceRegistryBuilder/ServiceRegistry and Metadatasources/Metadata smarlow left the room (quit: Ping timeout: 240 seconds). (17:14:34) emmanuel: And we had a sister class Ejb3Configuration that was used by users to set some of the properties like NamingStrategy, annotated classes etc emmanuel: Except that this Ejb3Configuration was building an EntityManagerFactory emmanuel: So the question is how do we move what Ejb3Cofiguration does today in the H4 model emmanuel: a. we keep it as is and use the new model underneath b. we expose a model similar to the new H4 model but that builds an EMF c. non of the above emmanuel: It should be noted that Ejb3configuration has a bunch of rules written in it that are specific to the specification emmanuel: so this code has to be somewhere hardy: fyi, this relates to issues HHH-6149 and HHH-6159 jbossbot: jira [HHH-6149] Clean up EJB3Configuration [Open (Unresolved) Improvement, Major, Steve Ebersole] http://opensource.atlassian.com/projects/hibernate/browse/HHH-6149 jbossbot: jira [HHH-6159] Determine best way to handle EntityManagerFactory building (EJB3Configuration) [Open (Unresolved) Task, Major, Steve Ebersole] http://opensource.atlassian.com/projects/hibernate/browse/HHH-6159 emmanuel: hardy: gbadner have you guys had to dig a bit into the Ejb3configuration code? sannegrinovero: do you want to support building both an EMF and a SessionFactory from the same base metadata ans serviceregistry? gbadner: no, I haven't hardy: i have not either yet emmanuel: sannegrinovero: not necessarily but we need to keep the flexibility for users to set all of the Hibernate concepts in a JPA configuration sannegrinovero: b. seems to be the most natural approach to me; I assume that the built EntityManagerFactory will be able to properly mandate the spec specifics.. maybe wrapping some metadata it needs with some spec-mandating adaptor. sannegrinovero is now known as sanne (17:20:16) emmanuel: sanne: yes I tend to agree with you emmanuel: I'm not sure we will be able to keep the ServiceRegistryBuilder "as is" or if we will need a JPAServiceREgistryBuilder emmanuel: (to mandate the rules) gbadner: emmanuel, in https://gist.github.com/942450 , do you enter a new context by calling .usingContext() again? sanne: I have no idea, but don't see why the registry would need any specific feature which wouldn't be useful to core as well. it's not that the registry needs to respect the spec. sanne: so any additional feature you need there, you can make it in the true and only ServiceRegistryBuilder emmanuel: gbadner: well context might not be the right term but the idea is that you are done with the "sources" and you want to give a different flavor to your Metadata object. For example bu default we use the DEfaultNamibngStrategy but you can override that using unsingContext() to set your own naming strategy emmanuel: is that clearer? emmanuel: usingContext() will return a specific object that will host the following methods: setNamingStrategy() and buildMetadata() gbadner: but how do you leave that context? emmanuel: note that buildMetadata is a method hosted on MetadataSources as well emmanuel: buildMetadata() leaves the context gbadner: hmm emmanuel: other names: usingContext(), withOptions(), getMetadataWithOptions() etc emmanuel: It's an approach we have used in Bean Validation to allo
Re: [hibernate-dev] Building a SessionFactory
Builder is a generic term. The specific function served here is that of a set of sources for metadata. The same does not hold for ServiceRegistryBuilder. It does not hold a singular type of information. In fact initially I shied away from the name ServiceRegistryBuilder because of its genericness. But in the end decided to use it because it would be familiar to developers. On 04/26/2011 11:05 AM, Emmanuel Bernard wrote: > I think we can converge by using the following approach. > https://gist.github.com/942450 > > Check the meeting logs, we have discussed the idea further. > > BTW it occurred to me that MetadataSources is more a builder than anything > else, should it be renamed to align with the service registry approach? > > On 22 avr. 2011, at 20:43, Steve Ebersole wrote: > >> I do not disagree, especially about the clutter. I had two related concerns >> with that this approach though: >> 1) minor, but this thing is then no longer just collecting the sources of >> metadata which is what a MetadataSources is. >> 2) this is no longer a "directed API" at all. What do I mean by that? Well: >> >> MetadataSources sources = new MetadataSources(...); >> sources.setNamingStrategy( strategy1 ); >> sources.addResource( "some/resource.xml" ); >> sources.setNamingStrategy( strategy2 ); >> sources.addResource( "some/resource2.xml" ); >> >> We are not "directing" the users to the correct usage of the API by the >> design of the API itself. >> >> >> Here is another option: >> MetadataSources sources = new MetadataSources(...) >> ... >> .getMetadataBuilder() >> .setNamingStrategy( ... ) >> .buildMetadata(); >> >> Now the naming strategy is associated with this "metadata builder" which is >> more semantically correct. But this is a bit verbose for today since I can >> only think of naming strategy as falling into this bucket. >> >> >> On 04/22/2011 03:37 AM, Emmanuel Bernard wrote: >>> My preference would go to a MetadataSources#setMetadata(NamingStrategy) >>> >>> My fear is that more functions could be needed overtime and make the >>> constructor or the buildMetadata signature cluttered and less readable. >>> >>> >>> On 21 avr. 2011, at 15:08, Steve Ebersole wrote: >>> NamingStrategy is not a service. It is solely a function of building the metadata. Currently, again, I have this set up via ctor param passing: new MetadataSources( reg, new MyNamingStrategy() ) Really its not logically part of the source, its needed during the transition from source->metadata, so an alternative I have been contemplating is: new MetadataSources( reg ).buildMetadata( new MyNamingStrategy() ) I am open to other suggestions. I really am trying to keep in mind the scope in which stuff is needed/useful/valid. On 04/21/2011 03:11 AM, Emmanuel Bernard wrote: > > On 21 avr. 2011, at 05:43, Steve Ebersole wrote: > >> I think this new API for creating a SessionFactory is starting to firm >> up, so I wanted to put out another call for feedback before we get too >> close to Alpha3. So at a high level there are 2 pieces of information >> needed to build the SessionFactory: the ServiceRegistry and the Metadata. >> >> ~ >> >> The ServiceRegistry is built through a ServiceRegistryBuilder (this is a >> slight recent change) >> >> Map config = ...; >> ServiceRegistry serviceRegistry = new ServiceRegistryBuilder( config ) >> ... >> .buildServiceRegistry(); >> >> The "..." allows you to add service instances and service initiators. >> Currently any (map of) configuration values is passed in the >> constructor. I can be convinced to allow adding/setting of config >> values as well, if everyone has a preference for that approach: >> >> Map config = ...; >> ServiceRegistry serviceRegistry = new ServiceRegistryBuilder() >> .setConfigurationData( config ) >> .setOption( Environment.SHOW_SQL, >> true ) >> ... >> .buildServiceRegistry(); >> >> Not sure the best method names there, to be honest which is why I opted >> for passing them to ctor. > > Is that a Mapor something a bit more refined? > > Regardless of the map being passed to the ctor, I'd think you need to > ability to set additional options (like you setOptions) > > Alternative names: > option: setting > > Not really related but, now that Configuration is gone, we lose some of > the type safety (like cfg.setNamingStrategy(new MyNamingStrategy() ), or > am I forgetting something in how the service registry works? > >> >> >> ~ >> >> Metadata is built through a MetadataSources which represents the sources >> of metadata information. >> >> Meta
Re: [hibernate-dev] Building a SessionFactory
I think we can converge by using the following approach. https://gist.github.com/942450 Check the meeting logs, we have discussed the idea further. BTW it occurred to me that MetadataSources is more a builder than anything else, should it be renamed to align with the service registry approach? On 22 avr. 2011, at 20:43, Steve Ebersole wrote: > I do not disagree, especially about the clutter. I had two related concerns > with that this approach though: > 1) minor, but this thing is then no longer just collecting the sources of > metadata which is what a MetadataSources is. > 2) this is no longer a "directed API" at all. What do I mean by that? Well: > > MetadataSources sources = new MetadataSources(...); > sources.setNamingStrategy( strategy1 ); > sources.addResource( "some/resource.xml" ); > sources.setNamingStrategy( strategy2 ); > sources.addResource( "some/resource2.xml" ); > > We are not "directing" the users to the correct usage of the API by the > design of the API itself. > > > Here is another option: > MetadataSources sources = new MetadataSources(...) >... >.getMetadataBuilder() >.setNamingStrategy( ... ) >.buildMetadata(); > > Now the naming strategy is associated with this "metadata builder" which is > more semantically correct. But this is a bit verbose for today since I can > only think of naming strategy as falling into this bucket. > > > On 04/22/2011 03:37 AM, Emmanuel Bernard wrote: >> My preference would go to a MetadataSources#setMetadata(NamingStrategy) >> >> My fear is that more functions could be needed overtime and make the >> constructor or the buildMetadata signature cluttered and less readable. >> >> >> On 21 avr. 2011, at 15:08, Steve Ebersole wrote: >> >>> NamingStrategy is not a service. It is solely a function of building the >>> metadata. >>> >>> Currently, again, I have this set up via ctor param passing: >>> >>> new MetadataSources( reg, new MyNamingStrategy() ) >>> >>> Really its not logically part of the source, its needed during the >>> transition from source->metadata, so an alternative I have been >>> contemplating is: >>> >>> new MetadataSources( reg ).buildMetadata( new MyNamingStrategy() ) >>> >>> I am open to other suggestions. I really am trying to keep in mind the >>> scope in which stuff is needed/useful/valid. >>> >>> >>> On 04/21/2011 03:11 AM, Emmanuel Bernard wrote: On 21 avr. 2011, at 05:43, Steve Ebersole wrote: > I think this new API for creating a SessionFactory is starting to firm > up, so I wanted to put out another call for feedback before we get too > close to Alpha3. So at a high level there are 2 pieces of information > needed to build the SessionFactory: the ServiceRegistry and the Metadata. > > ~ > > The ServiceRegistry is built through a ServiceRegistryBuilder (this is a > slight recent change) > > Map config = ...; > ServiceRegistry serviceRegistry = new ServiceRegistryBuilder( config ) > ... > .buildServiceRegistry(); > > The "..." allows you to add service instances and service initiators. > Currently any (map of) configuration values is passed in the > constructor. I can be convinced to allow adding/setting of config > values as well, if everyone has a preference for that approach: > > Map config = ...; > ServiceRegistry serviceRegistry = new ServiceRegistryBuilder() > .setConfigurationData( config ) > .setOption( Environment.SHOW_SQL, > true ) > ... > .buildServiceRegistry(); > > Not sure the best method names there, to be honest which is why I opted > for passing them to ctor. Is that a Map or something a bit more refined? Regardless of the map being passed to the ctor, I'd think you need to ability to set additional options (like you setOptions) Alternative names: option: setting Not really related but, now that Configuration is gone, we lose some of the type safety (like cfg.setNamingStrategy(new MyNamingStrategy() ), or am I forgetting something in how the service registry works? > > > ~ > > Metadata is built through a MetadataSources which represents the sources > of metadata information. > > MetadataSources metadataSources = new MetadataSources( serviceRegistry ) > .addResource( "some.hbm.xml" ) > .addAnnotatedClass( SomeEntity.class ); > Metadata metadata = metadataSources.buildMetadata(); > > > > ~ > > The Metadata is then used to obtain a SessionFactory. > > SessionFactory sf = metadata.buildSessionFactory(); > > > Metadata represents the "configuration time" mapping information. As of > now we will allo
Re: [hibernate-dev] one-to-one mapping
Please use the user forum http://forum.hibernate.org This mailing list is about theHibernate projects developments. On 26 avr. 2011, at 15:51, Faraz Fallahi wrote: > hi > > im trying to create a simple one-to-one mapping in my hbm files. > For Example: > > > is in the Tutor.hbm.xml > > My many to one, one to many and many to many mappings all work, but > one to one doesnt. i would expect him to create me an account id > column in my tutor table, but he does not. > what am i doing wrond? > > greez > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] one-to-one mapping
hi im trying to create a simple one-to-one mapping in my hbm files. For Example: is in the Tutor.hbm.xml My many to one, one to many and many to many mappings all work, but one to one doesnt. i would expect him to create me an account id column in my tutor table, but he does not. what am i doing wrond? greez ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Integrator and retrieving objects
as(...) is on Session though. What I am talking about is what happens
when they *somehow* get a normal Session and call session.as(
FullTextSession.class ) ?
e.g.
fullTextSession.getSessionFactory()
.openSession()
.as( FullTextSession.class );
Now what?
I guess this really gets to the intent of as(...).
Like I can see the usefulness of "light binding" the notions of a
Session and a FullTextSession (not so sure wrt AuditReader, I'd have to
understand the relation there a little better) such that the following
is valid:
normalHibernateSessionFactory.openSession()
.as( FullTextSession.class )
.()
But there are a lot of implications there. Like we need to be able to
make the SessionFactory aware of the other "sub factories" and track the
"sub sessions" per Session (lazily!).
Heck, I would *love* to see:
normalHibernateSessionFactory.openSession()
.as( EntityManager.class )
...
On 04/26/2011 01:31 AM, Sanne Grinovero wrote:
> 2011/4/25 Steve Ebersole:
>> Just to circle back to this (because my memory is so short)..
>>
>> What did we ever decide about this, especially in regards to the *how*?
>>
>> As and example, lets look at Search. Search wraps Session in a
>> FullTextSession. Search would register some handler with the
>> SessionFactory that says it knows how to handle Session.as(
>> FullTextSession.class ) calls. But what exactly is this handler going
>> to do? Unless Search maintains some global Session instance ->
>> FullTextSession instance... Or are you thinking the registration
>> happens per-Session?
>
> The entry points for Search are two:
> - the session *EventListener(s) (only one instance, but listening to
> multiple types of events)
> - the FullTextSession
>
> A FullTextSession needs a reference to the current session, and a
> reference to the SearchFactoryImplementor, which is the heavy-weight
> global component, similar to a SessionFactory.
>
> Currently a FullTextSession implements Session and is created from the
> Session it wraps using a static helper which searches for it's own
> PostInsertEventListener in the Session itself, from which it takes a
> reference to the needed SearchFactoryImplementor.
>
> I would be a nice improvement if the "as( FullTextSession.class )"
> implementation could retrieve the SearchFactoryImplementor from the
> ServiceRegistry instead.
>
> In pseudo code, the "as" implementation for search would look like something
> as:
>
> FullTextSession createFullTextSession() {
> return new FullTextSession( Session current, serviceRegistry.get(
> SearchFactoryImplementor.class ) );
> }
>
> (or even simpler if SessionImplementor makes it possible to retrieve services
> )
>
> Regards,
> Sanne
>
>>
>>
>> On 04/06/2011 09:28 AM, Emmanuel Bernard wrote:
>>> yes as is indeed better.
>>>
>>> On 6 avr. 2011, at 13:29, Steve Ebersole wrote:
>>>
A phrase I see a lot here is "as":
session.as( AuditReader.class ).someEnversSpecificMethod()
or
session.as( FullTextSession.class )...
On 04/06/2011 06:26 AM, Adam Warski wrote:
>
> On Apr 6, 2011, at 1:20 PM, Steve Ebersole wrote:
>
>> The phrase 'unwrap' might be a bit misleading there because you may not
>> be dealing with wrapped objects. But the idea itself is still solid I
>> believe. Think of it more as a multi-directional cast
>
> Right, the idea sounds good; so it would be something like a per-session
> service? :)
> Envers could use it as well, right now just as search has
> Search.getFullTextSession, envers has AuditReaderFactory.getFor
> So we could have session.service(AuditReader.class /
> FullTextSession.class).
>
> Adam
>
>> On Apr 6, 2011 6:15 AM, "Adam Warski" wrote:
>>>
FullTextSession ftSession = session.unwrap(FullTextSession.class);
//the current approach is via some static helper method
//FullTextSession ftSession = Search.getFullTextSession(session);
That would mean that the integration point between HSearch and
Hibernate would have an unwrap method and Hibernate would delegate the
unwrap calls to each integrator until a non null object is returned.
It's just a thought, WDYT?
>>>
>>> But while EntityManager wraps a Session object, a Session doesn't wrap
>>> a FullTextSession, but the other way round, no?
>>>
>>> --
>>> Adam Warski
>>> http://www.warski.org
>>> http://www.softwaremill.eu
>>>
>>>
>>>
>>>
>>>
>>> ___
>>> hibernate-dev mailing list
>>> hibernate-dev@lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
--
Steve Ebersole
http://hibernate.org
___
hibernate-dev mailing list
hibernate-dev@lists.
Re: [hibernate-dev] Hibernate OGM documentation
On 22 avr. 2011, at 19:22, Juraci Paixao Krohling wrote: > On 04/22/2011 06:43 PM, Emmanuel Bernard wrote: >> I've been working on Hibernate OGM documentation. I am still very unhappy >> with what I have but that's a start. >> >> You can read it at >> http://docs.jboss.org/hibernate/ogm/3.0/reference/en-US/html_single/ >> You can contribute to it by forking on github >> https://github.com/hibernate/hibernate-ogm > > Looks very good. I will submit some patches, related to some typos and > to make some things more explicit. > > I have a comment about the style, though. It seems you are adopting a > more "personal" style, using "we" and "I" in some sentences. This is > nice, I personally like it (makes the reader feel comfortable), but > there were a lot of JIRAs opened against Hibernate Core/EM/ANN > documentation at the time they were "productized". Interesting. Any decent book publisher will tell you being personal is much better ;) Provided the project is at its early cycle, I think I'll stay with this style for the time being: - we need to make people feel at home, not scare them ;) - that's my style and since I'll be writing most of the doc, it's better I do it naturally So far the doc is quite small, so changing them won't be too much work. ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Hibernate Search 3.5 or 4
some late answers: 2011/4/21 Emmanuel Bernard : > OK, if we want to do all of this we will hate to start very quickly. In > fairness, I'm not sure we can even do all of this so let's make sure these > are prioritized accordingly. > I could not find the expected deadlines for AS 7 / Cre 4 but we are probably > talking about June here: ie very soon. > > Some more comments inline. > > On 20 avr. 2011, at 10:21, Sanne Grinovero wrote: > >> Hi, >> About changing contracts, we don't get this chance very often so we >> should make sure we don't miss any. >> I have some favourites I'd like to discuss: >> >> - work list sent to backend >> -- As you know Lucene dropped all guarantees about serializability, >> supporting stuff like JMS requires a format change; especially the >> NumericField is not working right now as it was never serializable >> (HSEARCH-681) > > +1 > >> -- Lucene is being more flexible about updates, I don't think we >> should keep remapping an "update" operation as a delete+add operation, >> but transmit the "update operation" and let the backend figure out >> what's best. > > I guess we could do that. we need to make sure collections "updates" play > well in that mix. the urgent bit of the proposal is to add an "update" operation as a supported verb. there's no need to convert the collections updates from using a "delete+add" soon, I just mean to make it possible to later improve on this so that the contract allows it. >> - DirectoryProvider >> -- make a "DirectoryManager" instead, which is able to provide >> factories for both IndexReader an IndexWriters >> -- add utility methods like "getName()", wish I had that in some >> cases to provide better error messages. This leads me to think that >> instead of trying to foresee all needed methods, the extension point >> should not be the DirectoryManager interface directly, but have people >> plug in different aspects. > > That might be better also since it reduces the scope, it's easier to design > the contract. > >> -- this is needed to support both Instantiated indexes and to make >> good use of all new so called "Near-Real-Time" Lucene improvements. >> >> - ReaderProvider >> -- (assuming should a thing would still exist): I think it would be >> very nice if the responsibility of such a provider would be to provide >> the IndexReader for a single index. currently it has to provide a >> "multiReader" on each different index, making some implementations >> very tricky (seems I got it right in SharingBufferReaderProvider, but >> I recently had some other interesting ideas which revelaed quite >> dounting after a draft: take responsibility of the FieldCache expiry >> directly, to be able to plug different cache implementations, we >> control the lifecycle and we can be much smarter). > > ok, we might be able to do that in a 4.1 if need be. right, no need to make the new FieldCache integration, but we'd need to change the ReaderProvider API to work on a single index. > >> >> - backends and workers >> -- I'd like to make it possible to configure different backends per >> index. currently a backend is global, while in some cases (extreme) it >> would have been hand to configure even single shards to different >> backends. So really a backend should be something coupled to the >> "DirectoryManager" mentioned before. Question is, at what level is >> sharding going to work, it could work as a multiplexing >> DirectoryManager. > > Can you remind us the use case behind heterogeneous backends. There was one > but I forgot. it's mostly about performance details, the possibility to have different entities configured with different requirements: so for example one entity might have large indexes and use the rsync copy algorithm via the master/slave index providers configured to synch the index once per hour or day using async JMS as backend, while another entity requires transactional synchronization over the cluster and so might need an in sync JMS with the Infinispan directoryprovider. Currently people having such a requirement need to configure everything as synch. There was also a case in which people wanted to use a sharding strategy on top of this, to have some shards in high priority for the same entity; one corner use case even wanted to have a shard policy including a blackhole backend as one of the shards. > >> >> -- defaults to change: >> - remove the notions of transactional / batch IndexWriter setting, >> was deprecated since long enough. > > ok easy > >> - make the FullTextEventLister final (people still extent and replace >> it to better control when an entity is to be indexed, but I hope we >> can solve that as well) > > Well it will be in a private package anyways > >> - default to NumericField for numeric properties >> - set exclusive_index_use=true by default, benefits are far too high >> and some optimizations I was thinking of are impossible if this is >> disabled. > > I'm not sure I agree with that. It seems that such a defau
Re: [hibernate-dev] [infinispan-dev] Hibernate OGM documentation
Sorry for not providing any feedback on this as yet - I have an imminent transatlantic flight and I intend to catch up on all this reading then. :) On 22 Apr 2011, at 17:43, Emmanuel Bernard wrote: > Hi all > I've been working on Hibernate OGM documentation. I am still very unhappy > with what I have but that's a start. > > You can read it at > http://docs.jboss.org/hibernate/ogm/3.0/reference/en-US/html_single/ > You can contribute to it by forking on github > https://github.com/hibernate/hibernate-ogm > > To build the documentation, > - go to hibernate-ogm-doucumentation/manual > - run mvn install -DbuildDocs=true > You will get the result in target/docbook/publish/en-US > > I'm interested in all kind of feedback: > - general feel > - what part is confusing > - what you think is missing (besides the TODOs) > > And of course if you can contribute some part, that would be awesome. > > Emmanuel > > > > ___ > infinispan-dev mailing list > infinispan-...@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Manik Surtani ma...@jboss.org twitter.com/maniksurtani Lead, Infinispan http://www.infinispan.org ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
