From gunnar at hibernate.org  Tue Apr  1 03:20:28 2014
From: gunnar at hibernate.org (Gunnar Morling)
Date: Tue, 1 Apr 2014 09:20:28 +0200
Subject: [hibernate-dev] [OGM] CI jobs hang
Message-ID: <CADGJaX-qNW2x3E6nWaNBgyHAHk47A-HtwJwn_MruBm5Zb9YMmQ@mail.gmail.com>

Hi,

For some reason, the CI jobs for OGM can't be executed (all jobs, master,
java8, PR seem affected) . They hang forever in an initial state, i.e.
there is no console output and also the sub-jobs are not dispatched (these
are matrix projects). Worse, they can't even be canceled (trying to do so
has no effect), only a server restart helps.

Have there been any recent changes to the job (or server) config which may
cause this? I found https://issues.jenkins-ci.org/browse/JENKINS-9688 which
indicates, that the jobs may be waiting eternally for a resource which they
can't acquire (I don't see any resources requested in the job config, but I
vaguely remember something around JGroups channels).

Does anyone know what's going on here?

--Gunnar

From gunnar at hibernate.org  Tue Apr  1 07:24:22 2014
From: gunnar at hibernate.org (Gunnar Morling)
Date: Tue, 1 Apr 2014 13:24:22 +0200
Subject: [hibernate-dev] Session and carrying 3rd party state
In-Reply-To: <20140331150928.GF942@hibernate.org>
References: <20140320220523.GC10878@hibernate.org>
	<CADGJaX_OiD-n8+Fsn5ZiDNwjzbD3MJDkHTU102mskjusVOYnbQ@mail.gmail.com>
	<3D4548CC-17A6-4009-A463-17931C142D8D@hibernate.org>
	<CAFdSV9s1=+7JH9SRvCoCwwDVRQCKeiav+w1b=h7TKq3G8FfqEw@mail.gmail.com>
	<20140331150928.GF942@hibernate.org>
Message-ID: <CADGJaX_cQY2YKYcNraoktmTZaESFhHsgKZCHc4hUJG657QGidg@mail.gmail.com>

2014-03-31 17:09 GMT+02:00 Emmanuel Bernard <emmanuel at hibernate.org>:

> Gunnar, can you lead the work on getting that set of "fleshed out" use
> cases. With a bit of luck we could have them by tomorrow for the
> meeting and discuss them there.
>

I've started a document with use cases at
https://docs.google.com/document/d/13EOuMe8Ma6gacEyFUbH_KiNW0Yq1XKF26j-K7I6lHow/edit?usp=sharing.
Any comments welcome.


> BTW, as I said in my proposal the delegate does not work as there is not
> always a delegate object created.


> Emmanuel
>
> On Mon 2014-03-31  9:28, Steve Ebersole wrote:
> > Wasn't just me that said -1...
> >
> > My concerns are 2-fold:
> > 1) You want ORM to manage and expose "state storage" on Session even
> though
> > it does not use it.
> > 2) You want to store state in there that isnt even Session-scoped.
>  Rather
> > you have state that is scoped to a flush cycle, or to a transaction, etc.
> >
> > Really, as I said in the IRC meeting when we discussed this[1], I really
> > just want you guys to think through the use cases and flesh them out.
>  Then
> > in my opinion we start to see natural places to hook in state storage.
>  For
> > example, in the course of that IRC discussion we saw the need to store
> > things at the transaction-level become more clear and it seemed to me
> like
> > storing the state related to these transaction-scoped use-cases is just a
> > bad idea plain and simple.  You keep it relative to the transaction.
> >
> > To be honest I still have not seen that "fleshed out" discussion of use
> > cases, so its hard for me to say how state storage SHOULD be done.  But I
> > can certainly see ways that it SHOULD NOT be done.
> >
> > BTW, in looking through the discussion of getSessionOwner() again, I
> still
> > don't agree that was the right solution for what y'all want/need.
> > Ultimately the problem is that SessionImpl, not your delegate, gets
> passed
> > into the listeners/persisters/etc. And that happens because SessionImpl
> > passes `this` all the time. A simple solution would be to find all the
> > places that SessionImpl passes itself (`this`) into the places of
> interest
> > (creating events, calling persisters, etc) and to instead pass the
> delegate
> > via an override-able method that your delegate overriddes. For example,
> we
> > have this currently on SessionImpl:
> >
> >
> > @Override
> > public void persistOnFlush(String entityName, Object object, Map
> > copiedAlready) {
> >  firePersistOnFlush( copiedAlready, new PersistEvent( entityName, object,
> > this ) );
> >  }
> >
> > but IIUC the following would solve your problems in an even better way:
> >
> >   public EventSource getEventSource() {
> > return this;
> > }
> >
> > @Override
> > public void persistOnFlush(String entityName, Object object, Map
> > copiedAlready) {
> > firePersistOnFlush( copiedAlready, new PersistEvent( entityName, object,
> > getEventSource() ) );
> > }
> >
> >
> > and then your delegate would override this `getEventSource()` method to
> > return itself instead.
> >
> > The premise here is that ultimately we'd be better served actually
> getting
> > the OgmSession passed along to listeners/persisters.
> >
> >
> > [1]
> >
> http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2014/hibernate-dev.2014-03-11-15.46.log.html
> >
> >
> >
> > On Mon, Mar 31, 2014 at 7:31 AM, Emmanuel Bernard <
> emmanuel at hibernate.org>wrote:
> >
> > > The thing is, the map approach had a big -1 from Steve hanging on its
> head
> > > :)
> > >
> > > > On 31 mars 2014, at 12:07, Gunnar Morling <gunnar at hibernate.org>
> wrote:
> > > >
> > > >
> > > >
> > > >
> > > > 2014-03-20 23:05 GMT+01:00 Emmanuel Bernard <emmanuel at hibernate.org
> >:
> > > >> I took some more time to think about our conversation from 2 IRC
> > > meeting ago
> > > >> about offering the ability to carry session bound state not related
> to
> > > >> ORM per se.
> > > >> Below is a sum and a potential solution.
> > > >> If you are short on time, read Goals, then the
> > > SessionSessionEventListener
> > > >> approach and ignore the rest.
> > > >>
> > > >> ## Goals
> > > >>
> > > >> The goal is to be able to carry session bound state for non-ORM
> projects
> > > >> like search and OGM.
> > > >> We want to avoid ThreadLocal use, in particular when it cannot be
> > > >> protected by a try / catch for proper resource cleaning.
> > > >> We want to avoid a structure that would be shared across threads
> > > concurrently
> > > >> i.e. using ConcurrentHashMap with a Weak reference to the session.
> > > >> It needs to be informed of a call to session.clear()
> > > >> It needs to be informed of a call to session.close()
> > > >> The state needs to be accessed from event listener implementations
> and
> > > custom
> > > >> persister / loader implementations i.e. SessionImplementor and maybe
> > > >> EventSource?
> > > >>
> > > >> ## Approaches
> > > >>
> > > >> I'll discuss the approaches we explored in the meeting and then
> offer an
> > > >> alternative one that I think is pretty interesting and fit better
> with
> > > >> the current Session model.
> > > >>
> > > >> ### Map
> > > >>
> > > >> This is essentially sticking a map on SessionImpl and use it to
> carry
> > > >> state.
> > > >> The following is a pseudo implementation
> > > >>
> > > >>
> > > >>     /**
> > > >>      * interface implemented by SessionImpl and the like
> > > >>      */
> > > >>     interface SessionCompanion {
> > > >>         Object getCompanion(String key);
> > > >>         void addCompanion(String key, Object companion);
> > > >>         void removeCompanion(String key);
> > > >>     }
> > > >>
> > > >>
> > > >>     /**
> > > >>      * adds a map to the SessionImpl
> > > >>      */
> > > >>     SessionImpl {
> > > >>         private Map<String, Object> companions;
> > > >>         public Object getCompanion(String key) { return
> > > companions.get(key); }
> > > >>         public void addCompanion(String key, Object value) {
> > > companions.add(key, companion); }
> > > >>         public void removeCompanion(String key) {
> > > companions.remove(key) }
> > > >>     }
> > > >>
> > > >> The persister or event listener would call
> SessionCompation.*Companion
> > > method
> > > >> to put and retrieve its state.
> > > >>
> > > >> There is no clear / close event listener loop and it would need to
> be
> > > added.
> > > >>
> > > >> ### Delegator
> > > >>
> > > >> Gunnar and teve discussed an approach where the delegator would be
> > > passed to
> > > >> the underlying session and be accessible via an `unwrap` method.
> > > >> I have not followed the details but this approach has one major
> flaw:
> > > the
> > > >> delegator (OgmSession, FullTextSession etc) is not always created
> and
> > > thus
> > > >> would not be necessarily available.
> > > >> A somewhat similar idea involving passing the session owner has the
> same
> > > >> drawback. And another one described by Gunnar in
> > > >> https://hibernate.atlassian.net/browse/OGM-469
> > > >>
> > > >> ### The type-safe map approach
> > > >>
> > > >> This approach is vaguely similar to the Map approach except that the
> > > payload is
> > > >> represented and looked up by Class. This has the benefit of not
> having
> > > >> namespace problems and is generally less String-y.
> > > >>
> > > >>
> > > >>     /**
> > > >>      * interface implemented by SessionImpl and the like
> > > >>      */
> > > >>     interface SessionCompanion {
> > > >>         T getCompanion(Class<T> type);
> > > >>         void addCompanion(Object companion);
> > > >>         void removeCompanion(Class<?> type)
> > > >>
> > > >>     }
> > > >>
> > > >>
> > > >>     SessionImpl {
> > > >>         //could also use an array or an ArrayList
> > > >>         private Map<Class<?>, Object> companions;
> > > >>         public T getCompanion(Class<T> type) { return (T)
> > > companions.get(type); }
> > > >>         public void addCompanion(Object companion) {
> > > companions.add(companion.getClass(), type); }
> > > >>         public void removeCompanion(Class<T> type) {
> > > companions.remove(type); }
> > > >>     }
> > > >>
> > > >> Like in the Map approach, the persister or custom event listener
> would
> > > interact
> > > >> with SessionCompanion.
> > > >> There are open issues like what should be done when two objects of
> the
> > > same
> > > >> type are added to the same session.
> > > >> Likewise the clear / close hook issues need to be addressed.
> > > >>
> > > >> ### the SessionEventListener approach
> > > >>
> > > >> I did not know but there is a concept of `SessionEventListener`
> which
> > > can be
> > > >> added to a `SessionImplementor`. It has hooks that are addressing
> most
> > > of the
> > > >> goals.
> > > >>
> > > >>
> > > >>     //interface already exists
> > > >>     interface SessionImplementor {
> > > >>         public SessionEventListenerManager
> getEventListenerManager();
> > > >>     }
> > > >>
> > > >>     //interface already exists
> > > >>     public interface SessionEventListenerManager extends
> > > SessionEventListener {
> > > >>         // add this method to be able to retrieve a specific
> listener
> > > holding some state for a 3rd party project
> > > >>         List<SessionEventListener> getSessionEventListeners();
> > > >>     }
> > > >>
> > > >> OGM or Search would implement a `SessionEventListener` and attach an
> > > instance to a session via `Session.addEventListeners()`.
> > > >> It would require to add a method to retrieve the list of
> > > `SessionEventListener`s attached to a `SessionEventListenerManager`.
> > > >>
> > > >>     List<SessionEventListeners> listeners =
> > >
> sessionImplementor.getSessionEventListenerManager().getEnlistedListeners();
> > > >>     OgmSessionEventListener ogmListener =
> > > findOrAddOgmListener(sessionImplementor, listeners);
> > > >>     ogmListener.someStuff();
> > > >>
> > > >> ## What about clear and close?
> > > >>
> > > >> We have a few ways to react to these.
> > > >> SessionEventListener is already called back when a flush begins /
> ends
> > > as well as when Session closes.
> > > >> We need to either:
> > > >>
> > > >> - add a clear begins / ends callback
> > > >> - have the third party project add a ClearEventListener which would
> > > access the SessionEventListeners and do some magic.
> > > >>
> > > >> The first approach has my preference and would do:
> > > >>
> > > >>
> > > >>     public interface SessionEventListener {
> > > >>         [...]
> > > >>         void clearStart();
> > > >>         void clearEnd();
> > > >>     }
> > > >>
> > > >> What do you guys think? The SessionEventListener approach feels more
> > > natural.
> > > >
> > > > Tbh. I feel maintaining the state with a listener is a bit hacky. How
> > > would we find "our" listener, I guess it would involve some ugly
> instanceof
> > > check?
> > > >
> > > > The map based approaches seem preferable to me (I dislike the
> > > "companion" naming scheme though). The type-safe map approach is nice,
> as
> > > you say it may cause type collisions though and lead to a
> proliferation of
> > > key types. How about a combined approach which provides one such
> typesafe
> > > container per "client":
> > > >
> > > >     public interface SessionAttributes {
> > > >
> > > >         <T> T get(Class<T> type);
> > > >         <T> T put(Class<T> type, T value);
> > > >         <T> T remove(Class<T> type);
> > > >     }
> > > >
> > > > And
> > > >
> > > >     public interface SessionImplementor {
> > > >         ...
> > > >         SessionAttributes getAttributes(String integratorId);
> > > >     }
> > > >
> > > > And in OGM:
> > > >
> > > >     public static final String OGM_COMMON_ATTRIBUTES =
> > > "org.hibernate.ogm.attributes.common";
> > > >     ...
> > > >     FooBar fb =
> > > session.getAttributes(OGM_COMMON_ATTRIBUTES).get(FooBar.class);
> > > >
> > > > This avoids collisions of attributes of the same type between
> different
> > > clients such as OGM and Search (there could even be several attribute
> > > containers used by one client). The SessionAttributes could be
> instantiated
> > > lazily upon the first getAttributes() call, avoiding any overhead if
> the
> > > functionality is not used.
> > > >
> > > > The clean-up part (if it is required?) could then be done by an
> > > accompanying SessionEventListener.
> > > >
> > > > --Gunnar
> > > >
> > > >>
> > > >> Emmanuel
> > > >> _______________________________________________
> > > >> hibernate-dev mailing list
> > > >> hibernate-dev at lists.jboss.org
> > > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > > >
> > > _______________________________________________
> > > hibernate-dev mailing list
> > > hibernate-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > >
>

From gunnar at hibernate.org  Tue Apr  1 07:46:44 2014
From: gunnar at hibernate.org (Gunnar Morling)
Date: Tue, 1 Apr 2014 13:46:44 +0200
Subject: [hibernate-dev] Session and carrying 3rd party state
In-Reply-To: <CAFdSV9s1=+7JH9SRvCoCwwDVRQCKeiav+w1b=h7TKq3G8FfqEw@mail.gmail.com>
References: <20140320220523.GC10878@hibernate.org>
	<CADGJaX_OiD-n8+Fsn5ZiDNwjzbD3MJDkHTU102mskjusVOYnbQ@mail.gmail.com>
	<3D4548CC-17A6-4009-A463-17931C142D8D@hibernate.org>
	<CAFdSV9s1=+7JH9SRvCoCwwDVRQCKeiav+w1b=h7TKq3G8FfqEw@mail.gmail.com>
Message-ID: <CADGJaX8NM8fcQQqopRUWuRDs7Vb=GTuOpWR-MQ=WsMerTwC=Cg@mail.gmail.com>

2014-03-31 16:28 GMT+02:00 Steve Ebersole <steve at hibernate.org>:

> Wasn't just me that said -1...
>
> My concerns are 2-fold:
> 1) You want ORM to manage and expose "state storage" on Session even
> though it does not use it.
> 2) You want to store state in there that isnt even Session-scoped.  Rather
> you have state that is scoped to a flush cycle, or to a transaction, etc.
>

We have needs for storage with different scopes, but we never meant to
store all those at the session level. This discussion is about the
session-scoped storage only; flush cycle and TX scoped storage are
different pairs of shoes.


> Really, as I said in the IRC meeting when we discussed this[1], I really
> just want you guys to think through the use cases and flesh them out.  Then
> in my opinion we start to see natural places to hook in state storage.  For
> example, in the course of that IRC discussion we saw the need to store
> things at the transaction-level become more clear and it seemed to me like
> storing the state related to these transaction-scoped use-cases is just a
> bad idea plain and simple.  You keep it relative to the transaction.
>
> To be honest I still have not seen that "fleshed out" discussion of use
> cases, so its hard for me to say how state storage SHOULD be done.  But I
> can certainly see ways that it SHOULD NOT be done.
>
> BTW, in looking through the discussion of getSessionOwner() again, I
> still don't agree that was the right solution for what y'all want/need.
> Ultimately the problem is that SessionImpl, not your delegate, gets passed
> into the listeners/persisters/etc. And that happens because SessionImpl
> passes `this` all the time. A simple solution would be to find all the
> places that SessionImpl passes itself (`this`) into the places of
> interest (creating events, calling persisters, etc) and to instead pass the
> delegate via an override-able method that your delegate overriddes. For
> example, we have this currently on SessionImpl:
>
>
> @Override
> public void persistOnFlush(String entityName, Object object, Map
> copiedAlready) {
>  firePersistOnFlush( copiedAlready, new PersistEvent( entityName, object,
> this ) );
>  }
>
> but IIUC the following would solve your problems in an even better way:
>
>   public EventSource getEventSource() {
> return this;
>  }
>
>  @Override
>  public void persistOnFlush(String entityName, Object object, Map
> copiedAlready) {
>  firePersistOnFlush( copiedAlready, new PersistEvent( entityName, object,
> getEventSource() ) );
>  }
>
>
> and then your delegate would override this `getEventSource()` method to
> return itself instead.
>
> The premise here is that ultimately we'd be better served actually getting
> the OgmSession passed along to listeners/persisters.
>

That's an interesting idea; The problem is though, when creating an
OgmSession, the SessionImpl instance we delegate to has already been
created. So we'd need a setter for passing in the OgmSession as event
source. Or, we'd have to create a sub-class of SessionImpl:

    public class CustomEventSourceSessionImpl extends SessionImpl {

        private SessionImpl delegate;
        private EventSource es;

        public CustomEventSourceSessionImpl(SessionImpl delegate,
EventSource es) { ... }

        public EventSource getEventSource() { return es; }

        //all other methods delegate
    }

And in OgmSession:

    public OgmSession(OgmSessionFactory factory, EventSource delegate) {
        super( delegate, new CustomEventSourceSessionImpl( delegate, this )
);
        ...
    }

In the end it this forms a circular dependency between delegator
(OgmSession) and delegate (SessionImpl). Not sure whether that's a good
thing.

--Gunnar



[1]
> http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2014/hibernate-dev.2014-03-11-15.46.log.html
>
>
>
> On Mon, Mar 31, 2014 at 7:31 AM, Emmanuel Bernard <emmanuel at hibernate.org>wrote:
>
>> The thing is, the map approach had a big -1 from Steve hanging on its
>> head :)
>>
>> > On 31 mars 2014, at 12:07, Gunnar Morling <gunnar at hibernate.org> wrote:
>> >
>> >
>> >
>> >
>> > 2014-03-20 23:05 GMT+01:00 Emmanuel Bernard <emmanuel at hibernate.org>:
>> >> I took some more time to think about our conversation from 2 IRC
>> meeting ago
>> >> about offering the ability to carry session bound state not related to
>> >> ORM per se.
>> >> Below is a sum and a potential solution.
>> >> If you are short on time, read Goals, then the
>> SessionSessionEventListener
>> >> approach and ignore the rest.
>> >>
>> >> ## Goals
>> >>
>> >> The goal is to be able to carry session bound state for non-ORM
>> projects
>> >> like search and OGM.
>> >> We want to avoid ThreadLocal use, in particular when it cannot be
>> >> protected by a try / catch for proper resource cleaning.
>> >> We want to avoid a structure that would be shared across threads
>> concurrently
>> >> i.e. using ConcurrentHashMap with a Weak reference to the session.
>> >> It needs to be informed of a call to session.clear()
>> >> It needs to be informed of a call to session.close()
>> >> The state needs to be accessed from event listener implementations and
>> custom
>> >> persister / loader implementations i.e. SessionImplementor and maybe
>> >> EventSource?
>> >>
>> >> ## Approaches
>> >>
>> >> I'll discuss the approaches we explored in the meeting and then offer
>> an
>> >> alternative one that I think is pretty interesting and fit better with
>> >> the current Session model.
>> >>
>> >> ### Map
>> >>
>> >> This is essentially sticking a map on SessionImpl and use it to carry
>> >> state.
>> >> The following is a pseudo implementation
>> >>
>> >>
>> >>     /**
>> >>      * interface implemented by SessionImpl and the like
>> >>      */
>> >>     interface SessionCompanion {
>> >>         Object getCompanion(String key);
>> >>         void addCompanion(String key, Object companion);
>> >>         void removeCompanion(String key);
>> >>     }
>> >>
>> >>
>> >>     /**
>> >>      * adds a map to the SessionImpl
>> >>      */
>> >>     SessionImpl {
>> >>         private Map<String, Object> companions;
>> >>         public Object getCompanion(String key) { return
>> companions.get(key); }
>> >>         public void addCompanion(String key, Object value) {
>> companions.add(key, companion); }
>> >>         public void removeCompanion(String key) {
>> companions.remove(key) }
>> >>     }
>> >>
>> >> The persister or event listener would call SessionCompation.*Companion
>> method
>> >> to put and retrieve its state.
>> >>
>> >> There is no clear / close event listener loop and it would need to be
>> added.
>> >>
>> >> ### Delegator
>> >>
>> >> Gunnar and teve discussed an approach where the delegator would be
>> passed to
>> >> the underlying session and be accessible via an `unwrap` method.
>> >> I have not followed the details but this approach has one major flaw:
>> the
>> >> delegator (OgmSession, FullTextSession etc) is not always created and
>> thus
>> >> would not be necessarily available.
>> >> A somewhat similar idea involving passing the session owner has the
>> same
>> >> drawback. And another one described by Gunnar in
>> >> https://hibernate.atlassian.net/browse/OGM-469
>> >>
>> >> ### The type-safe map approach
>> >>
>> >> This approach is vaguely similar to the Map approach except that the
>> payload is
>> >> represented and looked up by Class. This has the benefit of not having
>> >> namespace problems and is generally less String-y.
>> >>
>> >>
>> >>     /**
>> >>      * interface implemented by SessionImpl and the like
>> >>      */
>> >>     interface SessionCompanion {
>> >>         T getCompanion(Class<T> type);
>> >>         void addCompanion(Object companion);
>> >>         void removeCompanion(Class<?> type)
>> >>
>> >>     }
>> >>
>> >>
>> >>     SessionImpl {
>> >>         //could also use an array or an ArrayList
>> >>         private Map<Class<?>, Object> companions;
>> >>         public T getCompanion(Class<T> type) { return (T)
>> companions.get(type); }
>> >>         public void addCompanion(Object companion) {
>> companions.add(companion.getClass(), type); }
>> >>         public void removeCompanion(Class<T> type) {
>> companions.remove(type); }
>> >>     }
>> >>
>> >> Like in the Map approach, the persister or custom event listener would
>> interact
>> >> with SessionCompanion.
>> >> There are open issues like what should be done when two objects of the
>> same
>> >> type are added to the same session.
>> >> Likewise the clear / close hook issues need to be addressed.
>> >>
>> >> ### the SessionEventListener approach
>> >>
>> >> I did not know but there is a concept of `SessionEventListener` which
>> can be
>> >> added to a `SessionImplementor`. It has hooks that are addressing most
>> of the
>> >> goals.
>> >>
>> >>
>> >>     //interface already exists
>> >>     interface SessionImplementor {
>> >>         public SessionEventListenerManager getEventListenerManager();
>> >>     }
>> >>
>> >>     //interface already exists
>> >>     public interface SessionEventListenerManager extends
>> SessionEventListener {
>> >>         // add this method to be able to retrieve a specific listener
>> holding some state for a 3rd party project
>> >>         List<SessionEventListener> getSessionEventListeners();
>> >>     }
>> >>
>> >> OGM or Search would implement a `SessionEventListener` and attach an
>> instance to a session via `Session.addEventListeners()`.
>> >> It would require to add a method to retrieve the list of
>> `SessionEventListener`s attached to a `SessionEventListenerManager`.
>> >>
>> >>     List<SessionEventListeners> listeners =
>> sessionImplementor.getSessionEventListenerManager().getEnlistedListeners();
>> >>     OgmSessionEventListener ogmListener =
>> findOrAddOgmListener(sessionImplementor, listeners);
>> >>     ogmListener.someStuff();
>> >>
>> >> ## What about clear and close?
>> >>
>> >> We have a few ways to react to these.
>> >> SessionEventListener is already called back when a flush begins / ends
>> as well as when Session closes.
>> >> We need to either:
>> >>
>> >> - add a clear begins / ends callback
>> >> - have the third party project add a ClearEventListener which would
>> access the SessionEventListeners and do some magic.
>> >>
>> >> The first approach has my preference and would do:
>> >>
>> >>
>> >>     public interface SessionEventListener {
>> >>         [...]
>> >>         void clearStart();
>> >>         void clearEnd();
>> >>     }
>> >>
>> >> What do you guys think? The SessionEventListener approach feels more
>> natural.
>> >
>> > Tbh. I feel maintaining the state with a listener is a bit hacky. How
>> would we find "our" listener, I guess it would involve some ugly instanceof
>> check?
>> >
>> > The map based approaches seem preferable to me (I dislike the
>> "companion" naming scheme though). The type-safe map approach is nice, as
>> you say it may cause type collisions though and lead to a proliferation of
>> key types. How about a combined approach which provides one such typesafe
>> container per "client":
>> >
>> >     public interface SessionAttributes {
>> >
>> >         <T> T get(Class<T> type);
>> >         <T> T put(Class<T> type, T value);
>> >         <T> T remove(Class<T> type);
>> >     }
>> >
>> > And
>> >
>> >     public interface SessionImplementor {
>> >         ...
>> >         SessionAttributes getAttributes(String integratorId);
>> >     }
>> >
>> > And in OGM:
>> >
>> >     public static final String OGM_COMMON_ATTRIBUTES =
>> "org.hibernate.ogm.attributes.common";
>> >     ...
>> >     FooBar fb =
>> session.getAttributes(OGM_COMMON_ATTRIBUTES).get(FooBar.class);
>> >
>> > This avoids collisions of attributes of the same type between different
>> clients such as OGM and Search (there could even be several attribute
>> containers used by one client). The SessionAttributes could be instantiated
>> lazily upon the first getAttributes() call, avoiding any overhead if the
>> functionality is not used.
>> >
>> > The clean-up part (if it is required?) could then be done by an
>> accompanying SessionEventListener.
>> >
>> > --Gunnar
>> >
>> >>
>> >> Emmanuel
>> >> _______________________________________________
>> >> hibernate-dev mailing list
>> >> hibernate-dev at lists.jboss.org
>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>

From paolo.antinori at gmail.com  Tue Apr  1 09:02:51 2014
From: paolo.antinori at gmail.com (Paolo Antinori)
Date: Tue, 1 Apr 2014 14:02:51 +0100
Subject: [hibernate-dev] [OGM] CI jobs hang (Gunnar Morling)
Message-ID: <CAO4Yhkg+2UGP094mzH5NP5a-dN1s_6_PFvoyeymv7-6tMKiQpw@mail.gmail.com>

Hi Gunnar

I am working on related activities on a replica of ci.hibernate.org where I
am playing with Docker and trying to see how well it could fit the the
project build needs.

When running OGM build job on this replica server, I have noticed the same
problem.

I think that the problem is related to Axis plugin, like you were pointing
out.

I have also noticed this:

http://ci.hibernate.org/job/hibernate-ogm-master/106/consoleText

That is the link for the plain text version of the logs.

Not sure if the message you find there:

No such file: /var/lib/jenkins/jobs/hibernate-ogm-master/builds/2014-04-01_07-01-01/log

Is the blocking problem or just a side-effect of something else.

I hope to be able to show soon a Docker based approach to possibly bypass
totally this kind of problems.

paolo


On Tue, Apr 1, 2014 at 12:46 PM, <hibernate-dev-request at lists.jboss.org>wrote:

> Send hibernate-dev mailing list submissions to
>         hibernate-dev at lists.jboss.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://lists.jboss.org/mailman/listinfo/hibernate-dev
> or, via email, send a message with subject or body 'help' to
>         hibernate-dev-request at lists.jboss.org
>
> You can reach the person managing the list at
>         hibernate-dev-owner at lists.jboss.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of hibernate-dev digest..."
>
> Today's Topics:
>
>    1. [OGM] CI jobs hang (Gunnar Morling)
>    2. Re: Session and carrying 3rd party state (Gunnar Morling)
>    3. Re: Session and carrying 3rd party state (Gunnar Morling)
>
>
> ---------- Forwarded message ----------
> From: Gunnar Morling <gunnar at hibernate.org>
> To: "hibernate-dev at lists.jboss.org" <hibernate-dev at lists.jboss.org>
> Cc:
> Date: Tue, 1 Apr 2014 09:20:28 +0200
> Subject: [hibernate-dev] [OGM] CI jobs hang
> Hi,
>
> For some reason, the CI jobs for OGM can't be executed (all jobs, master,
> java8, PR seem affected) . They hang forever in an initial state, i.e.
> there is no console output and also the sub-jobs are not dispatched (these
> are matrix projects). Worse, they can't even be canceled (trying to do so
> has no effect), only a server restart helps.
>
> Have there been any recent changes to the job (or server) config which may
> cause this? I found https://issues.jenkins-ci.org/browse/JENKINS-9688which
> indicates, that the jobs may be waiting eternally for a resource which they
> can't acquire (I don't see any resources requested in the job config, but I
> vaguely remember something around JGroups channels).
>
> Does anyone know what's going on here?
>
> --Gunnar
>
>
>

From gunnar at hibernate.org  Tue Apr  1 09:11:13 2014
From: gunnar at hibernate.org (Gunnar Morling)
Date: Tue, 1 Apr 2014 15:11:13 +0200
Subject: [hibernate-dev] [OGM] CI jobs hang (Gunnar Morling)
In-Reply-To: <CAO4Yhkg+2UGP094mzH5NP5a-dN1s_6_PFvoyeymv7-6tMKiQpw@mail.gmail.com>
References: <CAO4Yhkg+2UGP094mzH5NP5a-dN1s_6_PFvoyeymv7-6tMKiQpw@mail.gmail.com>
Message-ID: <CADGJaX_qBLTBc7qo9GrsQvxKxEqaX_f0_A2mSjUxOK59BV5FfQ@mail.gmail.com>

Hi Paolo,

Thanks for your reply. The thing is that these jobs used to work until
recently, so I'm wondering which change could be causing the problem. Maybe
a recent update to Jenkins or one of the plug-ins?

Unfortunately we don't have the config audit plug-in anymore which provides
a history at least of changes to job configs. @Davide, I think I had
installed it once but I guess it got lost when rebuilding the instance via
Puppet? Any chance you could add this plug-in permanently?

@Paolo: Would be very interested to learn more about the Docker stuff
you're working on once you got something :)

--Gunnar





2014-04-01 15:02 GMT+02:00 Paolo Antinori <paolo.antinori at gmail.com>:

> Hi Gunnar
>
> I am working on related activities on a replica of ci.hibernate.org where
> I
> am playing with Docker and trying to see how well it could fit the the
> project build needs.
>
> When running OGM build job on this replica server, I have noticed the same
> problem.
>
> I think that the problem is related to Axis plugin, like you were pointing
> out.
>
> I have also noticed this:
>
> http://ci.hibernate.org/job/hibernate-ogm-master/106/consoleText
>
> That is the link for the plain text version of the logs.
>
> Not sure if the message you find there:
>
> No such file:
> /var/lib/jenkins/jobs/hibernate-ogm-master/builds/2014-04-01_07-01-01/log
>
> Is the blocking problem or just a side-effect of something else.
>
> I hope to be able to show soon a Docker based approach to possibly bypass
> totally this kind of problems.
>
> paolo
>
>
> On Tue, Apr 1, 2014 at 12:46 PM, <hibernate-dev-request at lists.jboss.org
> >wrote:
>
> > Send hibernate-dev mailing list submissions to
> >         hibernate-dev at lists.jboss.org
> >
> > To subscribe or unsubscribe via the World Wide Web, visit
> >         https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > or, via email, send a message with subject or body 'help' to
> >         hibernate-dev-request at lists.jboss.org
> >
> > You can reach the person managing the list at
> >         hibernate-dev-owner at lists.jboss.org
> >
> > When replying, please edit your Subject line so it is more specific
> > than "Re: Contents of hibernate-dev digest..."
> >
> > Today's Topics:
> >
> >    1. [OGM] CI jobs hang (Gunnar Morling)
> >    2. Re: Session and carrying 3rd party state (Gunnar Morling)
> >    3. Re: Session and carrying 3rd party state (Gunnar Morling)
> >
> >
> > ---------- Forwarded message ----------
> > From: Gunnar Morling <gunnar at hibernate.org>
> > To: "hibernate-dev at lists.jboss.org" <hibernate-dev at lists.jboss.org>
> > Cc:
> > Date: Tue, 1 Apr 2014 09:20:28 +0200
> > Subject: [hibernate-dev] [OGM] CI jobs hang
> > Hi,
> >
> > For some reason, the CI jobs for OGM can't be executed (all jobs, master,
> > java8, PR seem affected) . They hang forever in an initial state, i.e.
> > there is no console output and also the sub-jobs are not dispatched
> (these
> > are matrix projects). Worse, they can't even be canceled (trying to do so
> > has no effect), only a server restart helps.
> >
> > Have there been any recent changes to the job (or server) config which
> may
> > cause this? I found
> https://issues.jenkins-ci.org/browse/JENKINS-9688which
> > indicates, that the jobs may be waiting eternally for a resource which
> they
> > can't acquire (I don't see any resources requested in the job config,
> but I
> > vaguely remember something around JGroups channels).
> >
> > Does anyone know what's going on here?
> >
> > --Gunnar
> >
> >
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Tue Apr  1 09:21:24 2014
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 1 Apr 2014 08:21:24 -0500
Subject: [hibernate-dev] ORM 3 JIRA tickets
In-Reply-To: <1637319301.4869337.1396296681197.JavaMail.zimbra@redhat.com>
References: <944961304.4838241.1396292959198.JavaMail.zimbra@redhat.com>
	<1095A2A7-5E69-4663-9753-D7E18F0EF669@hibernate.org>
	<756717593.4857958.1396295579250.JavaMail.zimbra@redhat.com>
	<CAFdSV9uaL6djBCA8gTokxJjPy9k63DVxM6Y8u20+seBkHugCmA@mail.gmail.com>
	<461055F8-B061-4725-A6A4-157421325633@hibernate.org>
	<1637319301.4869337.1396296681197.JavaMail.zimbra@redhat.com>
Message-ID: <CAFdSV9u_ywdq2B6i8i0O_nWQ95z2mcvML-UebEDnemz6OxuAsg@mail.gmail.com>

Nope.  Like I mentioned to you, I think this is, unfortunately, an evil
necessity at this point in time.


On Mon, Mar 31, 2014 at 3:11 PM, Brett Meyer <brmeyer at redhat.com> wrote:

> Good thoughts -- will do.  If anyone has differing opinions, I'm all ears.
>  I won't attempt this for a week or so...
>
> Brett Meyer
> Red Hat, Hibernate ORM
>
> ----- Original Message -----
> From: "Hardy Ferentschik" <hardy at hibernate.org>
> To: "Steve Ebersole" <steve at hibernate.org>
> Cc: "Brett Meyer" <brmeyer at redhat.com>, "Hibernate" <
> hibernate-dev at lists.jboss.org>
> Sent: Monday, March 31, 2014 4:06:25 PM
> Subject: Re: [hibernate-dev] ORM 3 JIRA tickets
>
>
> On 31 Jan 2014, at 22:01, Steve Ebersole <steve at hibernate.org> wrote:
>
> > Probably not a bad idea to write up a blog describing what we are doing
> and why.  We could link to that in the Jira comment
>
> +1, also an oppertunity to blog something else than ORM release blogs ;-)
>
>
>

From steve at hibernate.org  Tue Apr  1 10:36:45 2014
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 1 Apr 2014 09:36:45 -0500
Subject: [hibernate-dev] Session and carrying 3rd party state
In-Reply-To: <CADGJaX8NM8fcQQqopRUWuRDs7Vb=GTuOpWR-MQ=WsMerTwC=Cg@mail.gmail.com>
References: <20140320220523.GC10878@hibernate.org>
	<CADGJaX_OiD-n8+Fsn5ZiDNwjzbD3MJDkHTU102mskjusVOYnbQ@mail.gmail.com>
	<3D4548CC-17A6-4009-A463-17931C142D8D@hibernate.org>
	<CAFdSV9s1=+7JH9SRvCoCwwDVRQCKeiav+w1b=h7TKq3G8FfqEw@mail.gmail.com>
	<CADGJaX8NM8fcQQqopRUWuRDs7Vb=GTuOpWR-MQ=WsMerTwC=Cg@mail.gmail.com>
Message-ID: <CAFdSV9sdxCTO4jmN2_GVC5eNgSzJyWgqBo2kR6-PZ1L3TT_erA@mail.gmail.com>

In my opinion, any attempts to present a custom Session ought to inherently
mean presenting a custom SessionFactory.  I assume you also present a
OgmSessionFactory, so you should have total control over how a Session
creation happens.  At some point do you think maybe part of the problem is
"delegating too much"?  Delegation is a great pattern, but it has limits.
 I realize this is a bit simplistic, but essentially you want the
processing to go from OgmSession->Session->OgmSession.  Inherently there is
going to need to be some level of "circular dependency" here if using
delegation (`getSessionOwner()` is in fact a form of circular dependency).

Really it comes down to what you want.  If it were me, I'd want my Session
(OgmSession) being the thing that gets passed to listeners and persisters.
 Heck your persisters clearly expect to be able to access the OgmSession or
we would not be having this conversation :)  But that means not using
delegating as the basis for OgmSession, instead having OgmSession extend
"SessionImpl".  SessionImpl is final as I said, so this would mean either:
1) removing final from SessionImpl
2) creating a new `AbstractEventSourceSession` (name pending) that both
SessionImpl and OgmSession (etal) can extend from




On Tue, Apr 1, 2014 at 6:46 AM, Gunnar Morling <gunnar at hibernate.org> wrote:

> 2014-03-31 16:28 GMT+02:00 Steve Ebersole <steve at hibernate.org>:
>
> Wasn't just me that said -1...
>>
>> My concerns are 2-fold:
>> 1) You want ORM to manage and expose "state storage" on Session even
>> though it does not use it.
>> 2) You want to store state in there that isnt even Session-scoped.
>>  Rather you have state that is scoped to a flush cycle, or to a
>> transaction, etc.
>>
>
> We have needs for storage with different scopes, but we never meant to
> store all those at the session level. This discussion is about the
> session-scoped storage only; flush cycle and TX scoped storage are
> different pairs of shoes.
>
>
>> Really, as I said in the IRC meeting when we discussed this[1], I really
>> just want you guys to think through the use cases and flesh them out.  Then
>> in my opinion we start to see natural places to hook in state storage.  For
>> example, in the course of that IRC discussion we saw the need to store
>> things at the transaction-level become more clear and it seemed to me like
>> storing the state related to these transaction-scoped use-cases is just a
>> bad idea plain and simple.  You keep it relative to the transaction.
>>
>> To be honest I still have not seen that "fleshed out" discussion of use
>> cases, so its hard for me to say how state storage SHOULD be done.  But I
>> can certainly see ways that it SHOULD NOT be done.
>>
>> BTW, in looking through the discussion of getSessionOwner() again, I
>> still don't agree that was the right solution for what y'all want/need.
>> Ultimately the problem is that SessionImpl, not your delegate, gets passed
>> into the listeners/persisters/etc. And that happens because SessionImpl
>> passes `this` all the time. A simple solution would be to find all the
>> places that SessionImpl passes itself (`this`) into the places of
>> interest (creating events, calling persisters, etc) and to instead pass the
>> delegate via an override-able method that your delegate overriddes. For
>> example, we have this currently on SessionImpl:
>>
>>
>> @Override
>> public void persistOnFlush(String entityName, Object object, Map
>> copiedAlready) {
>>  firePersistOnFlush( copiedAlready, new PersistEvent( entityName,
>> object, this ) );
>>  }
>>
>> but IIUC the following would solve your problems in an even better way:
>>
>>   public EventSource getEventSource() {
>> return this;
>>  }
>>
>>  @Override
>>  public void persistOnFlush(String entityName, Object object, Map
>> copiedAlready) {
>>  firePersistOnFlush( copiedAlready, new PersistEvent( entityName, object,
>> getEventSource() ) );
>>  }
>>
>>
>> and then your delegate would override this `getEventSource()` method to
>> return itself instead.
>>
>> The premise here is that ultimately we'd be better served actually
>> getting the OgmSession passed along to listeners/persisters.
>>
>
> That's an interesting idea; The problem is though, when creating an
> OgmSession, the SessionImpl instance we delegate to has already been
> created. So we'd need a setter for passing in the OgmSession as event
> source. Or, we'd have to create a sub-class of SessionImpl:
>
>     public class CustomEventSourceSessionImpl extends SessionImpl {
>
>         private SessionImpl delegate;
>         private EventSource es;
>
>         public CustomEventSourceSessionImpl(SessionImpl delegate,
> EventSource es) { ... }
>
>         public EventSource getEventSource() { return es; }
>
>         //all other methods delegate
>     }
>
> And in OgmSession:
>
>     public OgmSession(OgmSessionFactory factory, EventSource delegate) {
>         super( delegate, new CustomEventSourceSessionImpl( delegate, this
> ) );
>         ...
>     }
>
> In the end it this forms a circular dependency between delegator
> (OgmSession) and delegate (SessionImpl). Not sure whether that's a good
> thing.
>
> --Gunnar
>
>
>
> [1]
>> http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2014/hibernate-dev.2014-03-11-15.46.log.html
>>
>>
>>
>> On Mon, Mar 31, 2014 at 7:31 AM, Emmanuel Bernard <emmanuel at hibernate.org
>> > wrote:
>>
>>> The thing is, the map approach had a big -1 from Steve hanging on its
>>> head :)
>>>
>>> > On 31 mars 2014, at 12:07, Gunnar Morling <gunnar at hibernate.org>
>>> wrote:
>>> >
>>> >
>>> >
>>> >
>>> > 2014-03-20 23:05 GMT+01:00 Emmanuel Bernard <emmanuel at hibernate.org>:
>>> >> I took some more time to think about our conversation from 2 IRC
>>> meeting ago
>>> >> about offering the ability to carry session bound state not related to
>>> >> ORM per se.
>>> >> Below is a sum and a potential solution.
>>> >> If you are short on time, read Goals, then the
>>> SessionSessionEventListener
>>> >> approach and ignore the rest.
>>> >>
>>> >> ## Goals
>>> >>
>>> >> The goal is to be able to carry session bound state for non-ORM
>>> projects
>>> >> like search and OGM.
>>> >> We want to avoid ThreadLocal use, in particular when it cannot be
>>> >> protected by a try / catch for proper resource cleaning.
>>> >> We want to avoid a structure that would be shared across threads
>>> concurrently
>>> >> i.e. using ConcurrentHashMap with a Weak reference to the session.
>>> >> It needs to be informed of a call to session.clear()
>>> >> It needs to be informed of a call to session.close()
>>> >> The state needs to be accessed from event listener implementations
>>> and custom
>>> >> persister / loader implementations i.e. SessionImplementor and maybe
>>> >> EventSource?
>>> >>
>>> >> ## Approaches
>>> >>
>>> >> I'll discuss the approaches we explored in the meeting and then offer
>>> an
>>> >> alternative one that I think is pretty interesting and fit better with
>>> >> the current Session model.
>>> >>
>>> >> ### Map
>>> >>
>>> >> This is essentially sticking a map on SessionImpl and use it to carry
>>> >> state.
>>> >> The following is a pseudo implementation
>>> >>
>>> >>
>>> >>     /**
>>> >>      * interface implemented by SessionImpl and the like
>>> >>      */
>>> >>     interface SessionCompanion {
>>> >>         Object getCompanion(String key);
>>> >>         void addCompanion(String key, Object companion);
>>> >>         void removeCompanion(String key);
>>> >>     }
>>> >>
>>> >>
>>> >>     /**
>>> >>      * adds a map to the SessionImpl
>>> >>      */
>>> >>     SessionImpl {
>>> >>         private Map<String, Object> companions;
>>> >>         public Object getCompanion(String key) { return
>>> companions.get(key); }
>>> >>         public void addCompanion(String key, Object value) {
>>> companions.add(key, companion); }
>>> >>         public void removeCompanion(String key) {
>>> companions.remove(key) }
>>> >>     }
>>> >>
>>> >> The persister or event listener would call
>>> SessionCompation.*Companion method
>>> >> to put and retrieve its state.
>>> >>
>>> >> There is no clear / close event listener loop and it would need to be
>>> added.
>>> >>
>>> >> ### Delegator
>>> >>
>>> >> Gunnar and teve discussed an approach where the delegator would be
>>> passed to
>>> >> the underlying session and be accessible via an `unwrap` method.
>>> >> I have not followed the details but this approach has one major flaw:
>>> the
>>> >> delegator (OgmSession, FullTextSession etc) is not always created and
>>> thus
>>> >> would not be necessarily available.
>>> >> A somewhat similar idea involving passing the session owner has the
>>> same
>>> >> drawback. And another one described by Gunnar in
>>> >> https://hibernate.atlassian.net/browse/OGM-469
>>> >>
>>> >> ### The type-safe map approach
>>> >>
>>> >> This approach is vaguely similar to the Map approach except that the
>>> payload is
>>> >> represented and looked up by Class. This has the benefit of not having
>>> >> namespace problems and is generally less String-y.
>>> >>
>>> >>
>>> >>     /**
>>> >>      * interface implemented by SessionImpl and the like
>>> >>      */
>>> >>     interface SessionCompanion {
>>> >>         T getCompanion(Class<T> type);
>>> >>         void addCompanion(Object companion);
>>> >>         void removeCompanion(Class<?> type)
>>> >>
>>> >>     }
>>> >>
>>> >>
>>> >>     SessionImpl {
>>> >>         //could also use an array or an ArrayList
>>> >>         private Map<Class<?>, Object> companions;
>>> >>         public T getCompanion(Class<T> type) { return (T)
>>> companions.get(type); }
>>> >>         public void addCompanion(Object companion) {
>>> companions.add(companion.getClass(), type); }
>>> >>         public void removeCompanion(Class<T> type) {
>>> companions.remove(type); }
>>> >>     }
>>> >>
>>> >> Like in the Map approach, the persister or custom event listener
>>> would interact
>>> >> with SessionCompanion.
>>> >> There are open issues like what should be done when two objects of
>>> the same
>>> >> type are added to the same session.
>>> >> Likewise the clear / close hook issues need to be addressed.
>>> >>
>>> >> ### the SessionEventListener approach
>>> >>
>>> >> I did not know but there is a concept of `SessionEventListener` which
>>> can be
>>> >> added to a `SessionImplementor`. It has hooks that are addressing
>>> most of the
>>> >> goals.
>>> >>
>>> >>
>>> >>     //interface already exists
>>> >>     interface SessionImplementor {
>>> >>         public SessionEventListenerManager getEventListenerManager();
>>> >>     }
>>> >>
>>> >>     //interface already exists
>>> >>     public interface SessionEventListenerManager extends
>>> SessionEventListener {
>>> >>         // add this method to be able to retrieve a specific listener
>>> holding some state for a 3rd party project
>>> >>         List<SessionEventListener> getSessionEventListeners();
>>> >>     }
>>> >>
>>> >> OGM or Search would implement a `SessionEventListener` and attach an
>>> instance to a session via `Session.addEventListeners()`.
>>> >> It would require to add a method to retrieve the list of
>>> `SessionEventListener`s attached to a `SessionEventListenerManager`.
>>> >>
>>> >>     List<SessionEventListeners> listeners =
>>> sessionImplementor.getSessionEventListenerManager().getEnlistedListeners();
>>> >>     OgmSessionEventListener ogmListener =
>>> findOrAddOgmListener(sessionImplementor, listeners);
>>> >>     ogmListener.someStuff();
>>> >>
>>> >> ## What about clear and close?
>>> >>
>>> >> We have a few ways to react to these.
>>> >> SessionEventListener is already called back when a flush begins /
>>> ends as well as when Session closes.
>>> >> We need to either:
>>> >>
>>> >> - add a clear begins / ends callback
>>> >> - have the third party project add a ClearEventListener which would
>>> access the SessionEventListeners and do some magic.
>>> >>
>>> >> The first approach has my preference and would do:
>>> >>
>>> >>
>>> >>     public interface SessionEventListener {
>>> >>         [...]
>>> >>         void clearStart();
>>> >>         void clearEnd();
>>> >>     }
>>> >>
>>> >> What do you guys think? The SessionEventListener approach feels more
>>> natural.
>>> >
>>> > Tbh. I feel maintaining the state with a listener is a bit hacky. How
>>> would we find "our" listener, I guess it would involve some ugly instanceof
>>> check?
>>> >
>>> > The map based approaches seem preferable to me (I dislike the
>>> "companion" naming scheme though). The type-safe map approach is nice, as
>>> you say it may cause type collisions though and lead to a proliferation of
>>> key types. How about a combined approach which provides one such typesafe
>>> container per "client":
>>> >
>>> >     public interface SessionAttributes {
>>> >
>>> >         <T> T get(Class<T> type);
>>> >         <T> T put(Class<T> type, T value);
>>> >         <T> T remove(Class<T> type);
>>> >     }
>>> >
>>> > And
>>> >
>>> >     public interface SessionImplementor {
>>> >         ...
>>> >         SessionAttributes getAttributes(String integratorId);
>>> >     }
>>> >
>>> > And in OGM:
>>> >
>>> >     public static final String OGM_COMMON_ATTRIBUTES =
>>> "org.hibernate.ogm.attributes.common";
>>> >     ...
>>> >     FooBar fb =
>>> session.getAttributes(OGM_COMMON_ATTRIBUTES).get(FooBar.class);
>>> >
>>> > This avoids collisions of attributes of the same type between
>>> different clients such as OGM and Search (there could even be several
>>> attribute containers used by one client). The SessionAttributes could be
>>> instantiated lazily upon the first getAttributes() call, avoiding any
>>> overhead if the functionality is not used.
>>> >
>>> > The clean-up part (if it is required?) could then be done by an
>>> accompanying SessionEventListener.
>>> >
>>> > --Gunnar
>>> >
>>> >>
>>> >> Emmanuel
>>> >> _______________________________________________
>>> >> hibernate-dev mailing list
>>> >> hibernate-dev at lists.jboss.org
>>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>> >
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>
>>
>

From emmanuel at hibernate.org  Tue Apr  1 10:36:36 2014
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Tue, 1 Apr 2014 16:36:36 +0200
Subject: [hibernate-dev] [HSEARCH] Autodiscoverable field bridges next steps
Message-ID: <4FF34AA8-4475-48ED-91D5-7C5A7528AD70@hibernate.org>

There has been a lot of discussions on the PR. Let me try and sum up my next steps and bootstrap some discussions.

To comment on a specific subject, create a separate thread per subject or this thread will be come a huge radiated tree :)

## @IndexedEmbedded and null

Apparently both Sanne and I discovered a feature implemented a while ago :)
There are some questions around it so I opened a separate issue to deal with the question https://hibernate.atlassian.net/browse/HSEARCH-1578

## References to field bridges

Despite being on an internal class, some implementations (Infinispan remove query at least) uses direct references to FieldBridge.SOME_BRIDGE.
I?ll reinstate them so that Sanne could integrate continuously HSearch 5 with Infinispan. I would prefer to see them go esp when we have the free form entity support and the idea of field bridge composition done.
https://hibernate.atlassian.net/browse/HSEARCH-1579

BTW can I move these references? Or should they stay on BridgeFactory?

## Handling duplicates

I had in mind the following logic.

Prevent custom bridge providers to offer bridges in the same situation. That would be an error at start up time as the alternative of picking up one of them does not seem very attractive. Then built-in bridges would be taken into account. It means that a custom bridge would be able to override a built-in bridge.

Another alternative is to explicitly give ordering priorities to between providers. I?d rather not go that way if possible.

Sanne questioned the idea of built-in bridge and would rather have all bridges handled equally and not allow duplication.
It seems that the current set of bridges cannot support that approach. When I developed the code, I realised that there is an ordering to respect. If I put the TikeBridgeProvider logic before the date and calendar bridgeProviders, then the DSLTest fails. I could not find why but it shows that we have some interdependencies at the moment.

## Splitting the BridgeProvider in two methods

A way make the inelegant code structure

    FieldBridge bridge = provider.provide(?);
    if ( bridge != null ) {
        return bridge
    }

Is to ask of the provider to answer two question:

- boolean canProvideBridgeFor(?)
- FieldBridge createFieldBridge(?)

The code would become

    if ( provider.canProvideBridgeFor(?) ) {
        return createFieldBridge(?)
    }

I will experiment with it to see if it creates in practice too much duplication of code at the provider level. Another concern is that if the answer to can? and create? are inconsistent, we are in trouble.

## AnnotatedElement

Hardy does not like us being tied to the actual physical annotation objects. I tend to agree with him as we would need to fake it for free-form entities.
Since he worked on Jandex and the ORM side of parsing, he will work on a proposal that abstracts us away from AnnotatedElement.
The alternative is to pass the XLayer objects but not everyone is fine of that abstraction.

## BridgeProvider Context object

I?ll change the BridgeProvider to offer some kind of Context object instead of the list of parameters we have today. That will make it more future proof.

## Finish the BridgeProvider conversion

I?ll finish the conversion of the BridgeFactory to delegate as much code to BridgeProviders

## Implementation of the service loader based discovery

Hardy proposes to make each BridgeProvider a Service in the ServiceManager sense. The idea being that when we make a compatible ServiceManager OSGi wise, it will also make a compatible bridge provider discoverer.
It looks fine to me but as Hardy pointed out, we would need to make the ServiceManager accept several implementations per Service.
I?d like to separate the bridge auto-discoverability feature from that ServiceManager improvement to stay focused.
We can converge the service discovery as soon as the SM gains the right capability.

Emmanuel

From steve at hibernate.org  Tue Apr  1 13:10:19 2014
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 1 Apr 2014 12:10:19 -0500
Subject: [hibernate-dev] IRC Developer Meeting - 4/1
Message-ID: <CAFdSV9siPqshHVdSa9jX5fG32VLdzoO6jxLf6YyBYWCgG8MDzw@mail.gmail.com>

Mainly discussed OGM and its need to store state relative to various
"scopes"...


[12:09] <jbott> Minutes:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2014/hibernate-dev.2014-04-01-14.51.html
[12:09] <jbott> Minutes (text):
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2014/hibernate-dev.2014-04-01-14.51.txt
[12:09] <jbott> Log:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2014/hibernate-dev.2014-04-01-14.51.log.html

From gunnar at hibernate.org  Tue Apr  1 13:32:06 2014
From: gunnar at hibernate.org (Gunnar Morling)
Date: Tue, 1 Apr 2014 19:32:06 +0200
Subject: [hibernate-dev] Session and carrying 3rd party state
In-Reply-To: <CAFdSV9sdxCTO4jmN2_GVC5eNgSzJyWgqBo2kR6-PZ1L3TT_erA@mail.gmail.com>
References: <20140320220523.GC10878@hibernate.org>
	<CADGJaX_OiD-n8+Fsn5ZiDNwjzbD3MJDkHTU102mskjusVOYnbQ@mail.gmail.com>
	<3D4548CC-17A6-4009-A463-17931C142D8D@hibernate.org>
	<CAFdSV9s1=+7JH9SRvCoCwwDVRQCKeiav+w1b=h7TKq3G8FfqEw@mail.gmail.com>
	<CADGJaX8NM8fcQQqopRUWuRDs7Vb=GTuOpWR-MQ=WsMerTwC=Cg@mail.gmail.com>
	<CAFdSV9sdxCTO4jmN2_GVC5eNgSzJyWgqBo2kR6-PZ1L3TT_erA@mail.gmail.com>
Message-ID: <CADGJaX9KQ6Gdtvw3u1FAOQkiO1oLuBAHP+Y0vsMTXSb4boMf7A@mail.gmail.com>

Ok, so here is what I took from today's meeting regarding the management of
state in Hibernate OGM:

1) For maintaining state specific to an entity (e.g. the original
store-specific representation it was loaded from, so it can be re-used
later on instead of going to the store again), ORM could be extended to
allow for custom EntityEntry (and CollectionEntry) implementations created
by a customizable factory; OGM would plug in its own implementation of that
factory (e.g. via a service)

2) For maintaining state bound to a specific session (e.g. session-level
options), we may either
a) use a custom SessionEventListener which is registered by OGM and
maintains this state; This requires a new method
SessionEventsManager#getListenerOfType(Class<T> type) in ORM which can be
used in OGM persisters etc. to access that listener and the state it
maintains
OR
b) have a specialized SessionImpl in OGM which maintains that state and
exposes it to persisters etc. This requires ORM's SessionImpl to be made
non-final

3) We did not discuss in depth OGM information bound to the transaction or
single flush cycles

Sanne said he might take a look into a POC for 1).

We need to decide for 2 a) or b), with Emmanuel's preference being a) and
Steve suggesting b) :) Both have their pro's and con's. What I like about
listeners is that they provide a nice way for passing in the information
via custom events, but I'm open to both.

3) is open for another time.

If any of this is wrong or incomplete, please correct or add.

--Gunnar




2014-04-01 16:36 GMT+02:00 Steve Ebersole <steve at hibernate.org>:

> In my opinion, any attempts to present a custom Session ought to
> inherently mean presenting a custom SessionFactory.  I assume you also
> present a OgmSessionFactory, so you should have total control over how a
> Session creation happens.  At some point do you think maybe part of the
> problem is "delegating too much"?  Delegation is a great pattern, but it
> has limits.  I realize this is a bit simplistic, but essentially you want
> the processing to go from OgmSession->Session->OgmSession.  Inherently
> there is going to need to be some level of "circular dependency" here if
> using delegation (`getSessionOwner()` is in fact a form of circular
> dependency).
>
> Really it comes down to what you want.  If it were me, I'd want my Session
> (OgmSession) being the thing that gets passed to listeners and persisters.
>  Heck your persisters clearly expect to be able to access the OgmSession or
> we would not be having this conversation :)  But that means not using
> delegating as the basis for OgmSession, instead having OgmSession extend
> "SessionImpl".  SessionImpl is final as I said, so this would mean either:
> 1) removing final from SessionImpl
> 2) creating a new `AbstractEventSourceSession` (name pending) that both
> SessionImpl and OgmSession (etal) can extend from
>
>
>
>
> On Tue, Apr 1, 2014 at 6:46 AM, Gunnar Morling <gunnar at hibernate.org>wrote:
>
>> 2014-03-31 16:28 GMT+02:00 Steve Ebersole <steve at hibernate.org>:
>>
>> Wasn't just me that said -1...
>>>
>>> My concerns are 2-fold:
>>> 1) You want ORM to manage and expose "state storage" on Session even
>>> though it does not use it.
>>> 2) You want to store state in there that isnt even Session-scoped.
>>>  Rather you have state that is scoped to a flush cycle, or to a
>>> transaction, etc.
>>>
>>
>> We have needs for storage with different scopes, but we never meant to
>> store all those at the session level. This discussion is about the
>> session-scoped storage only; flush cycle and TX scoped storage are
>> different pairs of shoes.
>>
>>
>>> Really, as I said in the IRC meeting when we discussed this[1], I really
>>> just want you guys to think through the use cases and flesh them out.  Then
>>> in my opinion we start to see natural places to hook in state storage.  For
>>> example, in the course of that IRC discussion we saw the need to store
>>> things at the transaction-level become more clear and it seemed to me like
>>> storing the state related to these transaction-scoped use-cases is just a
>>> bad idea plain and simple.  You keep it relative to the transaction.
>>>
>>> To be honest I still have not seen that "fleshed out" discussion of use
>>> cases, so its hard for me to say how state storage SHOULD be done.  But I
>>> can certainly see ways that it SHOULD NOT be done.
>>>
>>> BTW, in looking through the discussion of getSessionOwner() again, I
>>> still don't agree that was the right solution for what y'all want/need.
>>> Ultimately the problem is that SessionImpl, not your delegate, gets passed
>>> into the listeners/persisters/etc. And that happens because SessionImpl
>>> passes `this` all the time. A simple solution would be to find all the
>>> places that SessionImpl passes itself (`this`) into the places of
>>> interest (creating events, calling persisters, etc) and to instead pass the
>>> delegate via an override-able method that your delegate overriddes. For
>>> example, we have this currently on SessionImpl:
>>>
>>>
>>> @Override
>>> public void persistOnFlush(String entityName, Object object, Map
>>> copiedAlready) {
>>>  firePersistOnFlush( copiedAlready, new PersistEvent( entityName,
>>> object, this ) );
>>>  }
>>>
>>> but IIUC the following would solve your problems in an even better way:
>>>
>>>   public EventSource getEventSource() {
>>> return this;
>>>  }
>>>
>>>  @Override
>>>  public void persistOnFlush(String entityName, Object object, Map
>>> copiedAlready) {
>>>  firePersistOnFlush( copiedAlready, new PersistEvent( entityName,
>>> object, getEventSource() ) );
>>>  }
>>>
>>>
>>> and then your delegate would override this `getEventSource()` method to
>>> return itself instead.
>>>
>>> The premise here is that ultimately we'd be better served actually
>>> getting the OgmSession passed along to listeners/persisters.
>>>
>>
>> That's an interesting idea; The problem is though, when creating an
>> OgmSession, the SessionImpl instance we delegate to has already been
>> created. So we'd need a setter for passing in the OgmSession as event
>> source. Or, we'd have to create a sub-class of SessionImpl:
>>
>>     public class CustomEventSourceSessionImpl extends SessionImpl {
>>
>>         private SessionImpl delegate;
>>         private EventSource es;
>>
>>         public CustomEventSourceSessionImpl(SessionImpl delegate,
>> EventSource es) { ... }
>>
>>         public EventSource getEventSource() { return es; }
>>
>>         //all other methods delegate
>>     }
>>
>> And in OgmSession:
>>
>>     public OgmSession(OgmSessionFactory factory, EventSource delegate) {
>>         super( delegate, new CustomEventSourceSessionImpl( delegate, this
>> ) );
>>         ...
>>     }
>>
>> In the end it this forms a circular dependency between delegator
>> (OgmSession) and delegate (SessionImpl). Not sure whether that's a good
>> thing.
>>
>> --Gunnar
>>
>>
>>
>> [1]
>>> http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2014/hibernate-dev.2014-03-11-15.46.log.html
>>>
>>>
>>>
>>> On Mon, Mar 31, 2014 at 7:31 AM, Emmanuel Bernard <
>>> emmanuel at hibernate.org> wrote:
>>>
>>>> The thing is, the map approach had a big -1 from Steve hanging on its
>>>> head :)
>>>>
>>>> > On 31 mars 2014, at 12:07, Gunnar Morling <gunnar at hibernate.org>
>>>> wrote:
>>>> >
>>>> >
>>>> >
>>>> >
>>>> > 2014-03-20 23:05 GMT+01:00 Emmanuel Bernard <emmanuel at hibernate.org>:
>>>> >> I took some more time to think about our conversation from 2 IRC
>>>> meeting ago
>>>> >> about offering the ability to carry session bound state not related
>>>> to
>>>> >> ORM per se.
>>>> >> Below is a sum and a potential solution.
>>>> >> If you are short on time, read Goals, then the
>>>> SessionSessionEventListener
>>>> >> approach and ignore the rest.
>>>> >>
>>>> >> ## Goals
>>>> >>
>>>> >> The goal is to be able to carry session bound state for non-ORM
>>>> projects
>>>> >> like search and OGM.
>>>> >> We want to avoid ThreadLocal use, in particular when it cannot be
>>>> >> protected by a try / catch for proper resource cleaning.
>>>> >> We want to avoid a structure that would be shared across threads
>>>> concurrently
>>>> >> i.e. using ConcurrentHashMap with a Weak reference to the session.
>>>> >> It needs to be informed of a call to session.clear()
>>>> >> It needs to be informed of a call to session.close()
>>>> >> The state needs to be accessed from event listener implementations
>>>> and custom
>>>> >> persister / loader implementations i.e. SessionImplementor and maybe
>>>> >> EventSource?
>>>> >>
>>>> >> ## Approaches
>>>> >>
>>>> >> I'll discuss the approaches we explored in the meeting and then
>>>> offer an
>>>> >> alternative one that I think is pretty interesting and fit better
>>>> with
>>>> >> the current Session model.
>>>> >>
>>>> >> ### Map
>>>> >>
>>>> >> This is essentially sticking a map on SessionImpl and use it to carry
>>>> >> state.
>>>> >> The following is a pseudo implementation
>>>> >>
>>>> >>
>>>> >>     /**
>>>> >>      * interface implemented by SessionImpl and the like
>>>> >>      */
>>>> >>     interface SessionCompanion {
>>>> >>         Object getCompanion(String key);
>>>> >>         void addCompanion(String key, Object companion);
>>>> >>         void removeCompanion(String key);
>>>> >>     }
>>>> >>
>>>> >>
>>>> >>     /**
>>>> >>      * adds a map to the SessionImpl
>>>> >>      */
>>>> >>     SessionImpl {
>>>> >>         private Map<String, Object> companions;
>>>> >>         public Object getCompanion(String key) { return
>>>> companions.get(key); }
>>>> >>         public void addCompanion(String key, Object value) {
>>>> companions.add(key, companion); }
>>>> >>         public void removeCompanion(String key) {
>>>> companions.remove(key) }
>>>> >>     }
>>>> >>
>>>> >> The persister or event listener would call
>>>> SessionCompation.*Companion method
>>>> >> to put and retrieve its state.
>>>> >>
>>>> >> There is no clear / close event listener loop and it would need to
>>>> be added.
>>>> >>
>>>> >> ### Delegator
>>>> >>
>>>> >> Gunnar and teve discussed an approach where the delegator would be
>>>> passed to
>>>> >> the underlying session and be accessible via an `unwrap` method.
>>>> >> I have not followed the details but this approach has one major
>>>> flaw: the
>>>> >> delegator (OgmSession, FullTextSession etc) is not always created
>>>> and thus
>>>> >> would not be necessarily available.
>>>> >> A somewhat similar idea involving passing the session owner has the
>>>> same
>>>> >> drawback. And another one described by Gunnar in
>>>> >> https://hibernate.atlassian.net/browse/OGM-469
>>>> >>
>>>> >> ### The type-safe map approach
>>>> >>
>>>> >> This approach is vaguely similar to the Map approach except that the
>>>> payload is
>>>> >> represented and looked up by Class. This has the benefit of not
>>>> having
>>>> >> namespace problems and is generally less String-y.
>>>> >>
>>>> >>
>>>> >>     /**
>>>> >>      * interface implemented by SessionImpl and the like
>>>> >>      */
>>>> >>     interface SessionCompanion {
>>>> >>         T getCompanion(Class<T> type);
>>>> >>         void addCompanion(Object companion);
>>>> >>         void removeCompanion(Class<?> type)
>>>> >>
>>>> >>     }
>>>> >>
>>>> >>
>>>> >>     SessionImpl {
>>>> >>         //could also use an array or an ArrayList
>>>> >>         private Map<Class<?>, Object> companions;
>>>> >>         public T getCompanion(Class<T> type) { return (T)
>>>> companions.get(type); }
>>>> >>         public void addCompanion(Object companion) {
>>>> companions.add(companion.getClass(), type); }
>>>> >>         public void removeCompanion(Class<T> type) {
>>>> companions.remove(type); }
>>>> >>     }
>>>> >>
>>>> >> Like in the Map approach, the persister or custom event listener
>>>> would interact
>>>> >> with SessionCompanion.
>>>> >> There are open issues like what should be done when two objects of
>>>> the same
>>>> >> type are added to the same session.
>>>> >> Likewise the clear / close hook issues need to be addressed.
>>>> >>
>>>> >> ### the SessionEventListener approach
>>>> >>
>>>> >> I did not know but there is a concept of `SessionEventListener`
>>>> which can be
>>>> >> added to a `SessionImplementor`. It has hooks that are addressing
>>>> most of the
>>>> >> goals.
>>>> >>
>>>> >>
>>>> >>     //interface already exists
>>>> >>     interface SessionImplementor {
>>>> >>         public SessionEventListenerManager getEventListenerManager();
>>>> >>     }
>>>> >>
>>>> >>     //interface already exists
>>>> >>     public interface SessionEventListenerManager extends
>>>> SessionEventListener {
>>>> >>         // add this method to be able to retrieve a specific
>>>> listener holding some state for a 3rd party project
>>>> >>         List<SessionEventListener> getSessionEventListeners();
>>>> >>     }
>>>> >>
>>>> >> OGM or Search would implement a `SessionEventListener` and attach an
>>>> instance to a session via `Session.addEventListeners()`.
>>>> >> It would require to add a method to retrieve the list of
>>>> `SessionEventListener`s attached to a `SessionEventListenerManager`.
>>>> >>
>>>> >>     List<SessionEventListeners> listeners =
>>>> sessionImplementor.getSessionEventListenerManager().getEnlistedListeners();
>>>> >>     OgmSessionEventListener ogmListener =
>>>> findOrAddOgmListener(sessionImplementor, listeners);
>>>> >>     ogmListener.someStuff();
>>>> >>
>>>> >> ## What about clear and close?
>>>> >>
>>>> >> We have a few ways to react to these.
>>>> >> SessionEventListener is already called back when a flush begins /
>>>> ends as well as when Session closes.
>>>> >> We need to either:
>>>> >>
>>>> >> - add a clear begins / ends callback
>>>> >> - have the third party project add a ClearEventListener which would
>>>> access the SessionEventListeners and do some magic.
>>>> >>
>>>> >> The first approach has my preference and would do:
>>>> >>
>>>> >>
>>>> >>     public interface SessionEventListener {
>>>> >>         [...]
>>>> >>         void clearStart();
>>>> >>         void clearEnd();
>>>> >>     }
>>>> >>
>>>> >> What do you guys think? The SessionEventListener approach feels more
>>>> natural.
>>>> >
>>>> > Tbh. I feel maintaining the state with a listener is a bit hacky. How
>>>> would we find "our" listener, I guess it would involve some ugly instanceof
>>>> check?
>>>> >
>>>> > The map based approaches seem preferable to me (I dislike the
>>>> "companion" naming scheme though). The type-safe map approach is nice, as
>>>> you say it may cause type collisions though and lead to a proliferation of
>>>> key types. How about a combined approach which provides one such typesafe
>>>> container per "client":
>>>> >
>>>> >     public interface SessionAttributes {
>>>> >
>>>> >         <T> T get(Class<T> type);
>>>> >         <T> T put(Class<T> type, T value);
>>>> >         <T> T remove(Class<T> type);
>>>> >     }
>>>> >
>>>> > And
>>>> >
>>>> >     public interface SessionImplementor {
>>>> >         ...
>>>> >         SessionAttributes getAttributes(String integratorId);
>>>> >     }
>>>> >
>>>> > And in OGM:
>>>> >
>>>> >     public static final String OGM_COMMON_ATTRIBUTES =
>>>> "org.hibernate.ogm.attributes.common";
>>>> >     ...
>>>> >     FooBar fb =
>>>> session.getAttributes(OGM_COMMON_ATTRIBUTES).get(FooBar.class);
>>>> >
>>>> > This avoids collisions of attributes of the same type between
>>>> different clients such as OGM and Search (there could even be several
>>>> attribute containers used by one client). The SessionAttributes could be
>>>> instantiated lazily upon the first getAttributes() call, avoiding any
>>>> overhead if the functionality is not used.
>>>> >
>>>> > The clean-up part (if it is required?) could then be done by an
>>>> accompanying SessionEventListener.
>>>> >
>>>> > --Gunnar
>>>> >
>>>> >>
>>>> >> Emmanuel
>>>> >> _______________________________________________
>>>> >> hibernate-dev mailing list
>>>> >> hibernate-dev at lists.jboss.org
>>>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>> >
>>>> _______________________________________________
>>>> hibernate-dev mailing list
>>>> hibernate-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>
>>>
>>>
>>
>

From brmeyer at redhat.com  Tue Apr  1 14:04:47 2014
From: brmeyer at redhat.com (Brett Meyer)
Date: Tue, 1 Apr 2014 14:04:47 -0400 (EDT)
Subject: [hibernate-dev] ORM 3 JIRA tickets
In-Reply-To: <CAFdSV9uaL6djBCA8gTokxJjPy9k63DVxM6Y8u20+seBkHugCmA@mail.gmail.com>
References: <944961304.4838241.1396292959198.JavaMail.zimbra@redhat.com>
	<1095A2A7-5E69-4663-9753-D7E18F0EF669@hibernate.org>
	<756717593.4857958.1396295579250.JavaMail.zimbra@redhat.com>
	<CAFdSV9uaL6djBCA8gTokxJjPy9k63DVxM6Y8u20+seBkHugCmA@mail.gmail.com>
Message-ID: <1435147292.5545693.1396375487881.JavaMail.zimbra@redhat.com>

All, here's the write up.  Comments appreciated!

http://in.relation.to/Bloggers/HibernateORMJIRAPoliciesAndCleanUpTactics

Brett Meyer
Red Hat, Hibernate ORM

----- Original Message -----
From: "Steve Ebersole" <steve at hibernate.org>
To: "Brett Meyer" <brmeyer at redhat.com>
Cc: "Hardy Ferentschik" <hardy at hibernate.org>, "Hibernate" <hibernate-dev at lists.jboss.org>
Sent: Monday, March 31, 2014 4:01:38 PM
Subject: Re: [hibernate-dev] ORM 3 JIRA tickets

Probably not a bad idea to write up a blog describing what we are doing and
why.  We could link to that in the Jira comment


On Mon, Mar 31, 2014 at 2:52 PM, Brett Meyer <brmeyer at redhat.com> wrote:

> > I guess you would still include some features/improvements issues
>
> I'm sure some legitimate things may get caught up in this, but I'd rather
> try to clean things up aggressively, then re-open on a case-by-case basis.
>  If there's something we close that the community feels strongly about, the
> hope is that they'll comment on it and bring it to our attention.
>
> Brett Meyer
> Red Hat, Hibernate ORM
>
> ----- Original Message -----
> From: "Hardy Ferentschik" <hardy at hibernate.org>
> To: "Brett Meyer" <brmeyer at redhat.com>
> Cc: "Hibernate" <hibernate-dev at lists.jboss.org>
> Sent: Monday, March 31, 2014 3:40:55 PM
> Subject: Re: [hibernate-dev] ORM 3 JIRA tickets
>
>
> On 31 Jan 2014, at 21:09, Brett Meyer <brmeyer at redhat.com> wrote:
>
> > Recently, we've been trying to clean up ORM's JIRA tickets.  There are a
> lot of duplication, stale issues, etc.  One thought was pushing all ORM 3
> tickets to the "Awaiting Test Case" state and requesting a reproducer on
> ORM 4 or 5.  They would then fall under our policy of automatically
> rejecting those tickets that did not receive a test case within 3 months or
> so.
>
> Sounds like a fair attempt to try to get a grip on all these open issues.
>
> >  This obviously would not include new features/improvements, anything
> assigned to someone, etc.
>
> I guess you would still include some features/improvements issues, since
> Bug is the default issue type and some people don't change the type
> even so they describe a feature/improvement. But that might not be
> important.
>
> --Hardy
>
>
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Tue Apr  1 14:06:45 2014
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 1 Apr 2014 13:06:45 -0500
Subject: [hibernate-dev] Session and carrying 3rd party state
In-Reply-To: <CADGJaX9KQ6Gdtvw3u1FAOQkiO1oLuBAHP+Y0vsMTXSb4boMf7A@mail.gmail.com>
References: <20140320220523.GC10878@hibernate.org>
	<CADGJaX_OiD-n8+Fsn5ZiDNwjzbD3MJDkHTU102mskjusVOYnbQ@mail.gmail.com>
	<3D4548CC-17A6-4009-A463-17931C142D8D@hibernate.org>
	<CAFdSV9s1=+7JH9SRvCoCwwDVRQCKeiav+w1b=h7TKq3G8FfqEw@mail.gmail.com>
	<CADGJaX8NM8fcQQqopRUWuRDs7Vb=GTuOpWR-MQ=WsMerTwC=Cg@mail.gmail.com>
	<CAFdSV9sdxCTO4jmN2_GVC5eNgSzJyWgqBo2kR6-PZ1L3TT_erA@mail.gmail.com>
	<CADGJaX9KQ6Gdtvw3u1FAOQkiO1oLuBAHP+Y0vsMTXSb4boMf7A@mail.gmail.com>
Message-ID: <CAFdSV9tYUH0PFDPBreNc422xwf7_ab5mUhSEVGq6cdHPufcOnw@mail.gmail.com>

I think you got it.

By the way, just to clarify... I am not pushing one or the other.  I am
just asking that you realize that you are conceptually really wanting a
custom Session impl.  The reason I think this is important is that I have
seen many times the problems that come about down the road when we
implement things in a way that does not accurately model the problem at
hand.  It's important IMO to go into these decisions "eyes wide open".

Yes, (3) is still to be covered in depth.  We left that for another day.
 Assuming y'all go for (b) above, IMO "transaction scope" state very nicely
fits in Hibernate's local transaction Synchrnonization registry depending
on the state you need available.  To help facilitate that, I could
implement a similar concept to #getListenerOfType on the
org.hibernate.engine.transaction.spi.SynchronizationRegistry.
 Also understand that ORM does not have a nice encapsulation to hook "flush
cycle scoped" state to; flush-scoped state held on your SessionEventListener
is an option.




On Tue, Apr 1, 2014 at 12:32 PM, Gunnar Morling <gunnar at hibernate.org>wrote:

> Ok, so here is what I took from today's meeting regarding the management
> of state in Hibernate OGM:
>
> 1) For maintaining state specific to an entity (e.g. the original
> store-specific representation it was loaded from, so it can be re-used
> later on instead of going to the store again), ORM could be extended to
> allow for custom EntityEntry (and CollectionEntry) implementations created
> by a customizable factory; OGM would plug in its own implementation of that
> factory (e.g. via a service)
>
> 2) For maintaining state bound to a specific session (e.g. session-level
> options), we may either
> a) use a custom SessionEventListener which is registered by OGM and
> maintains this state; This requires a new method
> SessionEventsManager#getListenerOfType(Class<T> type) in ORM which can be
> used in OGM persisters etc. to access that listener and the state it
> maintains
> OR
> b) have a specialized SessionImpl in OGM which maintains that state and
> exposes it to persisters etc. This requires ORM's SessionImpl to be made
> non-final
>
> 3) We did not discuss in depth OGM information bound to the transaction or
> single flush cycles
>
> Sanne said he might take a look into a POC for 1).
>
> We need to decide for 2 a) or b), with Emmanuel's preference being a) and
> Steve suggesting b) :) Both have their pro's and con's. What I like about
> listeners is that they provide a nice way for passing in the information
> via custom events, but I'm open to both.
>
> 3) is open for another time.
>
> If any of this is wrong or incomplete, please correct or add.
>
> --Gunnar
>
>
>
>
> 2014-04-01 16:36 GMT+02:00 Steve Ebersole <steve at hibernate.org>:
>
> In my opinion, any attempts to present a custom Session ought to
>> inherently mean presenting a custom SessionFactory.  I assume you also
>> present a OgmSessionFactory, so you should have total control over how a
>> Session creation happens.  At some point do you think maybe part of the
>> problem is "delegating too much"?  Delegation is a great pattern, but it
>> has limits.  I realize this is a bit simplistic, but essentially you want
>> the processing to go from OgmSession->Session->OgmSession.  Inherently
>> there is going to need to be some level of "circular dependency" here if
>> using delegation (`getSessionOwner()` is in fact a form of circular
>> dependency).
>>
>> Really it comes down to what you want.  If it were me, I'd want my
>> Session (OgmSession) being the thing that gets passed to listeners and
>> persisters.  Heck your persisters clearly expect to be able to access the
>> OgmSession or we would not be having this conversation :)  But that means
>> not using delegating as the basis for OgmSession, instead having OgmSession
>> extend "SessionImpl".  SessionImpl is final as I said, so this would mean
>> either:
>> 1) removing final from SessionImpl
>> 2) creating a new `AbstractEventSourceSession` (name pending) that both
>> SessionImpl and OgmSession (etal) can extend from
>>
>>
>>
>>
>> On Tue, Apr 1, 2014 at 6:46 AM, Gunnar Morling <gunnar at hibernate.org>wrote:
>>
>>> 2014-03-31 16:28 GMT+02:00 Steve Ebersole <steve at hibernate.org>:
>>>
>>> Wasn't just me that said -1...
>>>>
>>>> My concerns are 2-fold:
>>>> 1) You want ORM to manage and expose "state storage" on Session even
>>>> though it does not use it.
>>>> 2) You want to store state in there that isnt even Session-scoped.
>>>>  Rather you have state that is scoped to a flush cycle, or to a
>>>> transaction, etc.
>>>>
>>>
>>> We have needs for storage with different scopes, but we never meant to
>>> store all those at the session level. This discussion is about the
>>> session-scoped storage only; flush cycle and TX scoped storage are
>>> different pairs of shoes.
>>>
>>>
>>>> Really, as I said in the IRC meeting when we discussed this[1], I
>>>> really just want you guys to think through the use cases and flesh them
>>>> out.  Then in my opinion we start to see natural places to hook in state
>>>> storage.  For example, in the course of that IRC discussion we saw the need
>>>> to store things at the transaction-level become more clear and it seemed to
>>>> me like storing the state related to these transaction-scoped use-cases is
>>>> just a bad idea plain and simple.  You keep it relative to the transaction.
>>>>
>>>> To be honest I still have not seen that "fleshed out" discussion of use
>>>> cases, so its hard for me to say how state storage SHOULD be done.  But I
>>>> can certainly see ways that it SHOULD NOT be done.
>>>>
>>>> BTW, in looking through the discussion of getSessionOwner() again, I
>>>> still don't agree that was the right solution for what y'all want/need.
>>>> Ultimately the problem is that SessionImpl, not your delegate, gets passed
>>>> into the listeners/persisters/etc. And that happens because SessionImpl
>>>> passes `this` all the time. A simple solution would be to find all the
>>>> places that SessionImpl passes itself (`this`) into the places of
>>>> interest (creating events, calling persisters, etc) and to instead pass the
>>>> delegate via an override-able method that your delegate overriddes. For
>>>> example, we have this currently on SessionImpl:
>>>>
>>>>
>>>> @Override
>>>> public void persistOnFlush(String entityName, Object object, Map
>>>> copiedAlready) {
>>>>  firePersistOnFlush( copiedAlready, new PersistEvent( entityName,
>>>> object, this ) );
>>>>  }
>>>>
>>>> but IIUC the following would solve your problems in an even better way:
>>>>
>>>>   public EventSource getEventSource() {
>>>> return this;
>>>>  }
>>>>
>>>>  @Override
>>>>  public void persistOnFlush(String entityName, Object object, Map
>>>> copiedAlready) {
>>>>  firePersistOnFlush( copiedAlready, new PersistEvent( entityName,
>>>> object, getEventSource() ) );
>>>>  }
>>>>
>>>>
>>>> and then your delegate would override this `getEventSource()` method
>>>> to return itself instead.
>>>>
>>>> The premise here is that ultimately we'd be better served actually
>>>> getting the OgmSession passed along to listeners/persisters.
>>>>
>>>
>>> That's an interesting idea; The problem is though, when creating an
>>> OgmSession, the SessionImpl instance we delegate to has already been
>>> created. So we'd need a setter for passing in the OgmSession as event
>>> source. Or, we'd have to create a sub-class of SessionImpl:
>>>
>>>     public class CustomEventSourceSessionImpl extends SessionImpl {
>>>
>>>         private SessionImpl delegate;
>>>         private EventSource es;
>>>
>>>         public CustomEventSourceSessionImpl(SessionImpl delegate,
>>> EventSource es) { ... }
>>>
>>>         public EventSource getEventSource() { return es; }
>>>
>>>         //all other methods delegate
>>>     }
>>>
>>> And in OgmSession:
>>>
>>>     public OgmSession(OgmSessionFactory factory, EventSource delegate) {
>>>         super( delegate, new CustomEventSourceSessionImpl( delegate,
>>> this ) );
>>>         ...
>>>     }
>>>
>>> In the end it this forms a circular dependency between delegator
>>> (OgmSession) and delegate (SessionImpl). Not sure whether that's a good
>>> thing.
>>>
>>> --Gunnar
>>>
>>>
>>>
>>> [1]
>>>> http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2014/hibernate-dev.2014-03-11-15.46.log.html
>>>>
>>>>
>>>>
>>>> On Mon, Mar 31, 2014 at 7:31 AM, Emmanuel Bernard <
>>>> emmanuel at hibernate.org> wrote:
>>>>
>>>>> The thing is, the map approach had a big -1 from Steve hanging on its
>>>>> head :)
>>>>>
>>>>> > On 31 mars 2014, at 12:07, Gunnar Morling <gunnar at hibernate.org>
>>>>> wrote:
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>> > 2014-03-20 23:05 GMT+01:00 Emmanuel Bernard <emmanuel at hibernate.org
>>>>> >:
>>>>> >> I took some more time to think about our conversation from 2 IRC
>>>>> meeting ago
>>>>> >> about offering the ability to carry session bound state not related
>>>>> to
>>>>> >> ORM per se.
>>>>> >> Below is a sum and a potential solution.
>>>>> >> If you are short on time, read Goals, then the
>>>>> SessionSessionEventListener
>>>>> >> approach and ignore the rest.
>>>>> >>
>>>>> >> ## Goals
>>>>> >>
>>>>> >> The goal is to be able to carry session bound state for non-ORM
>>>>> projects
>>>>> >> like search and OGM.
>>>>> >> We want to avoid ThreadLocal use, in particular when it cannot be
>>>>> >> protected by a try / catch for proper resource cleaning.
>>>>> >> We want to avoid a structure that would be shared across threads
>>>>> concurrently
>>>>> >> i.e. using ConcurrentHashMap with a Weak reference to the session.
>>>>> >> It needs to be informed of a call to session.clear()
>>>>> >> It needs to be informed of a call to session.close()
>>>>> >> The state needs to be accessed from event listener implementations
>>>>> and custom
>>>>> >> persister / loader implementations i.e. SessionImplementor and maybe
>>>>> >> EventSource?
>>>>> >>
>>>>> >> ## Approaches
>>>>> >>
>>>>> >> I'll discuss the approaches we explored in the meeting and then
>>>>> offer an
>>>>> >> alternative one that I think is pretty interesting and fit better
>>>>> with
>>>>> >> the current Session model.
>>>>> >>
>>>>> >> ### Map
>>>>> >>
>>>>> >> This is essentially sticking a map on SessionImpl and use it to
>>>>> carry
>>>>> >> state.
>>>>> >> The following is a pseudo implementation
>>>>> >>
>>>>> >>
>>>>> >>     /**
>>>>> >>      * interface implemented by SessionImpl and the like
>>>>> >>      */
>>>>> >>     interface SessionCompanion {
>>>>> >>         Object getCompanion(String key);
>>>>> >>         void addCompanion(String key, Object companion);
>>>>> >>         void removeCompanion(String key);
>>>>> >>     }
>>>>> >>
>>>>> >>
>>>>> >>     /**
>>>>> >>      * adds a map to the SessionImpl
>>>>> >>      */
>>>>> >>     SessionImpl {
>>>>> >>         private Map<String, Object> companions;
>>>>> >>         public Object getCompanion(String key) { return
>>>>> companions.get(key); }
>>>>> >>         public void addCompanion(String key, Object value) {
>>>>> companions.add(key, companion); }
>>>>> >>         public void removeCompanion(String key) {
>>>>> companions.remove(key) }
>>>>> >>     }
>>>>> >>
>>>>> >> The persister or event listener would call
>>>>> SessionCompation.*Companion method
>>>>> >> to put and retrieve its state.
>>>>> >>
>>>>> >> There is no clear / close event listener loop and it would need to
>>>>> be added.
>>>>> >>
>>>>> >> ### Delegator
>>>>> >>
>>>>> >> Gunnar and teve discussed an approach where the delegator would be
>>>>> passed to
>>>>> >> the underlying session and be accessible via an `unwrap` method.
>>>>> >> I have not followed the details but this approach has one major
>>>>> flaw: the
>>>>> >> delegator (OgmSession, FullTextSession etc) is not always created
>>>>> and thus
>>>>> >> would not be necessarily available.
>>>>> >> A somewhat similar idea involving passing the session owner has the
>>>>> same
>>>>> >> drawback. And another one described by Gunnar in
>>>>> >> https://hibernate.atlassian.net/browse/OGM-469
>>>>> >>
>>>>> >> ### The type-safe map approach
>>>>> >>
>>>>> >> This approach is vaguely similar to the Map approach except that
>>>>> the payload is
>>>>> >> represented and looked up by Class. This has the benefit of not
>>>>> having
>>>>> >> namespace problems and is generally less String-y.
>>>>> >>
>>>>> >>
>>>>> >>     /**
>>>>> >>      * interface implemented by SessionImpl and the like
>>>>> >>      */
>>>>> >>     interface SessionCompanion {
>>>>> >>         T getCompanion(Class<T> type);
>>>>> >>         void addCompanion(Object companion);
>>>>> >>         void removeCompanion(Class<?> type)
>>>>> >>
>>>>> >>     }
>>>>> >>
>>>>> >>
>>>>> >>     SessionImpl {
>>>>> >>         //could also use an array or an ArrayList
>>>>> >>         private Map<Class<?>, Object> companions;
>>>>> >>         public T getCompanion(Class<T> type) { return (T)
>>>>> companions.get(type); }
>>>>> >>         public void addCompanion(Object companion) {
>>>>> companions.add(companion.getClass(), type); }
>>>>> >>         public void removeCompanion(Class<T> type) {
>>>>> companions.remove(type); }
>>>>> >>     }
>>>>> >>
>>>>> >> Like in the Map approach, the persister or custom event listener
>>>>> would interact
>>>>> >> with SessionCompanion.
>>>>> >> There are open issues like what should be done when two objects of
>>>>> the same
>>>>> >> type are added to the same session.
>>>>> >> Likewise the clear / close hook issues need to be addressed.
>>>>> >>
>>>>> >> ### the SessionEventListener approach
>>>>> >>
>>>>> >> I did not know but there is a concept of `SessionEventListener`
>>>>> which can be
>>>>> >> added to a `SessionImplementor`. It has hooks that are addressing
>>>>> most of the
>>>>> >> goals.
>>>>> >>
>>>>> >>
>>>>> >>     //interface already exists
>>>>> >>     interface SessionImplementor {
>>>>> >>         public SessionEventListenerManager
>>>>> getEventListenerManager();
>>>>> >>     }
>>>>> >>
>>>>> >>     //interface already exists
>>>>> >>     public interface SessionEventListenerManager extends
>>>>> SessionEventListener {
>>>>> >>         // add this method to be able to retrieve a specific
>>>>> listener holding some state for a 3rd party project
>>>>> >>         List<SessionEventListener> getSessionEventListeners();
>>>>> >>     }
>>>>> >>
>>>>> >> OGM or Search would implement a `SessionEventListener` and attach
>>>>> an instance to a session via `Session.addEventListeners()`.
>>>>> >> It would require to add a method to retrieve the list of
>>>>> `SessionEventListener`s attached to a `SessionEventListenerManager`.
>>>>> >>
>>>>> >>     List<SessionEventListeners> listeners =
>>>>> sessionImplementor.getSessionEventListenerManager().getEnlistedListeners();
>>>>> >>     OgmSessionEventListener ogmListener =
>>>>> findOrAddOgmListener(sessionImplementor, listeners);
>>>>> >>     ogmListener.someStuff();
>>>>> >>
>>>>> >> ## What about clear and close?
>>>>> >>
>>>>> >> We have a few ways to react to these.
>>>>> >> SessionEventListener is already called back when a flush begins /
>>>>> ends as well as when Session closes.
>>>>> >> We need to either:
>>>>> >>
>>>>> >> - add a clear begins / ends callback
>>>>> >> - have the third party project add a ClearEventListener which would
>>>>> access the SessionEventListeners and do some magic.
>>>>> >>
>>>>> >> The first approach has my preference and would do:
>>>>> >>
>>>>> >>
>>>>> >>     public interface SessionEventListener {
>>>>> >>         [...]
>>>>> >>         void clearStart();
>>>>> >>         void clearEnd();
>>>>> >>     }
>>>>> >>
>>>>> >> What do you guys think? The SessionEventListener approach feels
>>>>> more natural.
>>>>> >
>>>>> > Tbh. I feel maintaining the state with a listener is a bit hacky.
>>>>> How would we find "our" listener, I guess it would involve some ugly
>>>>> instanceof check?
>>>>> >
>>>>> > The map based approaches seem preferable to me (I dislike the
>>>>> "companion" naming scheme though). The type-safe map approach is nice, as
>>>>> you say it may cause type collisions though and lead to a proliferation of
>>>>> key types. How about a combined approach which provides one such typesafe
>>>>> container per "client":
>>>>> >
>>>>> >     public interface SessionAttributes {
>>>>> >
>>>>> >         <T> T get(Class<T> type);
>>>>> >         <T> T put(Class<T> type, T value);
>>>>> >         <T> T remove(Class<T> type);
>>>>> >     }
>>>>> >
>>>>> > And
>>>>> >
>>>>> >     public interface SessionImplementor {
>>>>> >         ...
>>>>> >         SessionAttributes getAttributes(String integratorId);
>>>>> >     }
>>>>> >
>>>>> > And in OGM:
>>>>> >
>>>>> >     public static final String OGM_COMMON_ATTRIBUTES =
>>>>> "org.hibernate.ogm.attributes.common";
>>>>> >     ...
>>>>> >     FooBar fb =
>>>>> session.getAttributes(OGM_COMMON_ATTRIBUTES).get(FooBar.class);
>>>>> >
>>>>> > This avoids collisions of attributes of the same type between
>>>>> different clients such as OGM and Search (there could even be several
>>>>> attribute containers used by one client). The SessionAttributes could be
>>>>> instantiated lazily upon the first getAttributes() call, avoiding any
>>>>> overhead if the functionality is not used.
>>>>> >
>>>>> > The clean-up part (if it is required?) could then be done by an
>>>>> accompanying SessionEventListener.
>>>>> >
>>>>> > --Gunnar
>>>>> >
>>>>> >>
>>>>> >> Emmanuel
>>>>> >> _______________________________________________
>>>>> >> hibernate-dev mailing list
>>>>> >> hibernate-dev at lists.jboss.org
>>>>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>> >
>>>>> _______________________________________________
>>>>> hibernate-dev mailing list
>>>>> hibernate-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>
>>>>
>>>>
>>>
>>
>

From hardy at hibernate.org  Tue Apr  1 14:39:26 2014
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Tue, 1 Apr 2014 20:39:26 +0200
Subject: [hibernate-dev] ORM 3 JIRA tickets
In-Reply-To: <1435147292.5545693.1396375487881.JavaMail.zimbra@redhat.com>
References: <944961304.4838241.1396292959198.JavaMail.zimbra@redhat.com>
	<1095A2A7-5E69-4663-9753-D7E18F0EF669@hibernate.org>
	<756717593.4857958.1396295579250.JavaMail.zimbra@redhat.com>
	<CAFdSV9uaL6djBCA8gTokxJjPy9k63DVxM6Y8u20+seBkHugCmA@mail.gmail.com>
	<1435147292.5545693.1396375487881.JavaMail.zimbra@redhat.com>
Message-ID: <756E2881-B5AA-4C61-9801-8E3E0DF878B6@hibernate.org>

Nice. I think the approach makes sense in our current situation, and I also like that we clearly explain 
what we are trying to do and why.

Good stuff.

?Hardy



On 1 Jan 2014, at 20:04, Brett Meyer <brmeyer at redhat.com> wrote:

> All, here's the write up.  Comments appreciated!
> 
> http://in.relation.to/Bloggers/HibernateORMJIRAPoliciesAndCleanUpTactics
> 
> Brett Meyer
> Red Hat, Hibernate ORM
> 
> ----- Original Message -----
> From: "Steve Ebersole" <steve at hibernate.org>
> To: "Brett Meyer" <brmeyer at redhat.com>
> Cc: "Hardy Ferentschik" <hardy at hibernate.org>, "Hibernate" <hibernate-dev at lists.jboss.org>
> Sent: Monday, March 31, 2014 4:01:38 PM
> Subject: Re: [hibernate-dev] ORM 3 JIRA tickets
> 
> Probably not a bad idea to write up a blog describing what we are doing and
> why.  We could link to that in the Jira comment
> 
> 
> On Mon, Mar 31, 2014 at 2:52 PM, Brett Meyer <brmeyer at redhat.com> wrote:
> 
>>> I guess you would still include some features/improvements issues
>> 
>> I'm sure some legitimate things may get caught up in this, but I'd rather
>> try to clean things up aggressively, then re-open on a case-by-case basis.
>> If there's something we close that the community feels strongly about, the
>> hope is that they'll comment on it and bring it to our attention.
>> 
>> Brett Meyer
>> Red Hat, Hibernate ORM
>> 
>> ----- Original Message -----
>> From: "Hardy Ferentschik" <hardy at hibernate.org>
>> To: "Brett Meyer" <brmeyer at redhat.com>
>> Cc: "Hibernate" <hibernate-dev at lists.jboss.org>
>> Sent: Monday, March 31, 2014 3:40:55 PM
>> Subject: Re: [hibernate-dev] ORM 3 JIRA tickets
>> 
>> 
>> On 31 Jan 2014, at 21:09, Brett Meyer <brmeyer at redhat.com> wrote:
>> 
>>> Recently, we've been trying to clean up ORM's JIRA tickets.  There are a
>> lot of duplication, stale issues, etc.  One thought was pushing all ORM 3
>> tickets to the "Awaiting Test Case" state and requesting a reproducer on
>> ORM 4 or 5.  They would then fall under our policy of automatically
>> rejecting those tickets that did not receive a test case within 3 months or
>> so.
>> 
>> Sounds like a fair attempt to try to get a grip on all these open issues.
>> 
>>> This obviously would not include new features/improvements, anything
>> assigned to someone, etc.
>> 
>> I guess you would still include some features/improvements issues, since
>> Bug is the default issue type and some people don't change the type
>> even so they describe a feature/improvement. But that might not be
>> important.
>> 
>> --Hardy
>> 
>> 
>> 
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> 



From hardy at hibernate.org  Tue Apr  1 15:55:55 2014
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Tue, 1 Apr 2014 21:55:55 +0200
Subject: [hibernate-dev] [Search] OSGi split packages
In-Reply-To: <8480E93F-07B8-41AC-8C8F-1EAAE6C15D5C@hibernate.org>
References: <A1266C7A-710A-46A9-8404-C717E0E7470F@hibernate.org>
	<20140326125527.GF42990@hibernate.org>
	<CAFm4XO0w0Mhn1Mp39i9NHJ0wwBFXggQ4dCWW4g5=okpS2Guxgg@mail.gmail.com>
	<31054C8E-FF12-4589-8338-ECA99EA312F0@hibernate.org>
	<CAFm4XO3Yw6sKXyiFWdms-2WMtu9ZCrVt3_E9vae=AifYqKr_2g@mail.gmail.com>
	<D1F7DC82-AA37-4247-828A-5BD2E7EB173F@hibernate.org>
	<20140327131725.GP42990@hibernate.org>
	<0F6F7795-82E6-4746-B8D5-C04A050D0F4B@hibernate.org>
	<8480E93F-07B8-41AC-8C8F-1EAAE6C15D5C@hibernate.org>
Message-ID: <ACDA8A6A-4202-455B-9263-05AB2285211B@hibernate.org>

I dropped the ball on the package split for a couple of days, but would like to get this completed now.

> It seems we are all ok except on the SearchFactory shuffling.

Good :-)

> Not we we agree (or disagree) on that one.

I am not quite sure how to read this sentence, but I think in an earlier email you suggested to move 
SearchFactory into org.hibernate.search.boostrap.SearchFactory. My problem with this is that:

1) This package does not even exist yet. Moving just SearchFactory into it seems odd and I am not sure
    where your plan was to move other classes as well (for example SearchFactoryBuilder)
2) SearchFactory is more the result of bootstrapping and has its use beyond the scope of bootstrapping

As a reminder, in my working branch I moved org.hibernate.search.SearchFactory into
org.hibernate.search.spi.SearchFactory. My reasoning was that this package already contained
(rightfully or not) SearchFactoryIntegrator and SearchFactoryBuilder (the latter I find strange in an spi).

In case having SearchFactory in an spi package makes you a bit uneasy, you are not alone. I feel the 
same way. On the other hand, Sanne had some ideas and future plans where SearchFactory actually becomes 
an SPI. I don?t think that we all understand his vision here though.

Last but not least, another suggestion of a new home - org.hibernate.search.engine.SearchFactory.

Thoughts? 

?Hardy




From hardy at hibernate.org  Tue Apr  1 16:02:31 2014
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Tue, 1 Apr 2014 22:02:31 +0200
Subject: [hibernate-dev] [HSEARCH] Autodiscoverable field bridges next
	steps
In-Reply-To: <4FF34AA8-4475-48ED-91D5-7C5A7528AD70@hibernate.org>
References: <4FF34AA8-4475-48ED-91D5-7C5A7528AD70@hibernate.org>
Message-ID: <A0097193-2279-4D2F-8479-151DAF38E4E8@hibernate.org>


On 1 Jan 2014, at 16:36, Emmanuel Bernard <emmanuel at hibernate.org> wrote:

> ## References to field bridges
> 
> Despite being on an internal class, some implementations (Infinispan remove query at least) uses direct references to FieldBridge.SOME_BRIDGE.

IMO, they should not. There is a unnecessary coupling here. Easiest way for Infinispan is to use their own bridge

> I?ll reinstate them so that Sanne could integrate continuously HSearch 5 with Infinispan.

What does reinstate mean for Search 5 mean? For the next Alpha release, until Beta or even for Final. 

> I would prefer to see them go

+1 I would do it as part of this work. I don?t see a point in keeping them

?Hardy

From hardy at hibernate.org  Tue Apr  1 16:07:26 2014
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Tue, 1 Apr 2014 22:07:26 +0200
Subject: [hibernate-dev] [HSEARCH] Autodiscoverable field bridges next
	steps
In-Reply-To: <4FF34AA8-4475-48ED-91D5-7C5A7528AD70@hibernate.org>
References: <4FF34AA8-4475-48ED-91D5-7C5A7528AD70@hibernate.org>
Message-ID: <D6A3D1B3-1509-4CC8-B630-E3CB4A5FE841@hibernate.org>


On 1 Jan 2014, at 16:36, Emmanuel Bernard <emmanuel at hibernate.org> wrote:

> ## Handling duplicates
> 
> I had in mind the following logic.
> 
> Prevent custom bridge providers to offer bridges in the same situation.

What do you mean with "in the same situation?? You mean there cannot be two bridge providers for the same return type (assuming no dedicated bridge annotation)

> That would be an error at start up time as the alternative of picking up one of them does not seem very attractive.

How do you determine bridge providers providing bridges for the ?same situation??

> Sanne questioned the idea of built-in bridge and would rather have all bridges handled equally and not allow duplication.
> It seems that the current set of bridges cannot support that approach. When I developed the code, I realised that there is an ordering to respect. If I put the TikeBridgeProvider logic before the date and calendar bridgeProviders, then the DSLTest fails. I could not find why but it shows that we have some interdependencies at the moment.

I think it would be a good idea to fine out what?s going on first.

?Hardy



From hardy at hibernate.org  Tue Apr  1 16:19:33 2014
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Tue, 1 Apr 2014 22:19:33 +0200
Subject: [hibernate-dev] [HSEARCH] Autodiscoverable field bridges next
	steps
In-Reply-To: <4FF34AA8-4475-48ED-91D5-7C5A7528AD70@hibernate.org>
References: <4FF34AA8-4475-48ED-91D5-7C5A7528AD70@hibernate.org>
Message-ID: <81792793-F8F1-4242-86B1-BCB0349D07CE@hibernate.org>


On 1 Jan 2014, at 16:36, Emmanuel Bernard <emmanuel at hibernate.org> wrote:

> ## Splitting the BridgeProvider in two methods
> 
> A way make the inelegant code structure
> 
>    FieldBridge bridge = provider.provide(?);
>    if ( bridge != null ) {
>        return bridge
>    }
> 
> Is to ask of the provider to answer two question:
> 
> - boolean canProvideBridgeFor(?)
> - FieldBridge createFieldBridge(?)
> 
> The code would become
> 
>    if ( provider.canProvideBridgeFor(?) ) {
>        return createFieldBridge(?)
>    }

I prefer the latter. I tried already all sorts of arguments on the pull requests, but it might be that I stand alone here.
I think it is more intuitive since it avoids the null check and I almost can implement the provider without looking at the Javadocs 
telling my what to do. Also in the real world, you would first ask me whether I can make you something, before telling me to do so, right?

One of the counter arguments I?ve heard is, that having two methods instead of one creates some code duplication in the implementation.
I find this a weak argument. If I look at the API I first look at what I want this API to do and how it should do it. Whether the impl needs to repeat
some piece of code is a different question. And if nothing else, the implementation can extract the common code into a method. 

> Another concern is that if the answer to can? and create? are inconsistent, we are in trouble.

Well, if canProvideBridgeFor returns true it should create the bridge when provide is called. Unless there is of course an (runtime) error when creating
the bridge. However, this would throw an exception. If the bridge provider does not behave this way, you have indeed a bug, but I don?t see the big difference
to this type of bug to any other implementation error.

?Hardy



From hardy at hibernate.org  Tue Apr  1 16:20:09 2014
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Tue, 1 Apr 2014 22:20:09 +0200
Subject: [hibernate-dev] [HSEARCH] Autodiscoverable field bridges next
	steps
In-Reply-To: <4FF34AA8-4475-48ED-91D5-7C5A7528AD70@hibernate.org>
References: <4FF34AA8-4475-48ED-91D5-7C5A7528AD70@hibernate.org>
Message-ID: <37838A2C-BE3F-4CD2-92AB-2A31F4756C2D@hibernate.org>


On 1 Jan 2014, at 16:36, Emmanuel Bernard <emmanuel at hibernate.org> wrote:

> ## AnnotatedElement
> 
> Hardy does not like us being tied to the actual physical annotation objects. I tend to agree with him as we would need to fake it for free-form entities.
> Since he worked on Jandex and the ORM side of parsing, he will work on a proposal that abstracts us away from AnnotatedElement.
> The alternative is to pass the XLayer objects but not everyone is fine of that abstraction.

+1 Need to think a bit about it.



From hardy at hibernate.org  Tue Apr  1 16:24:04 2014
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Tue, 1 Apr 2014 22:24:04 +0200
Subject: [hibernate-dev] [HSEARCH] Autodiscoverable field bridges next
	steps
In-Reply-To: <4FF34AA8-4475-48ED-91D5-7C5A7528AD70@hibernate.org>
References: <4FF34AA8-4475-48ED-91D5-7C5A7528AD70@hibernate.org>
Message-ID: <7E4F5385-5C6A-4CA5-B039-C902F6D9B328@hibernate.org>


On 1 Jan 2014, at 16:36, Emmanuel Bernard <emmanuel at hibernate.org> wrote:

> ## Implementation of the service loader based discovery
> 
> Hardy proposes to make each BridgeProvider a Service in the ServiceManager sense.

It is right? We allow users to provide their implementations. 

> The idea being that when we make a compatible ServiceManager OSGi wise, it will also make a compatible bridge provider discoverer.

That?s a nice side effect imo. Depending on far you want to go with OSGi, you probably want to skip at some stage Java?s ServiceLoader
and do service lookups via OSGi mechanism. Doing Java service loading all via our ServiceManager ensures that we just have one (pluggable)
spot in case we want to down the OSGi service route.

> It looks fine to me but as Hardy pointed out, we would need to make the ServiceManager accept several implementations per Service.
> I?d like to separate the bridge auto-discoverability feature from that ServiceManager improvement to stay focused.
> We can converge the service discovery as soon as the SM gains the right capability.

Do you have a separate issue for the SessionManager enhancements? 

?Hardy



From gunnar at hibernate.org  Tue Apr  1 16:55:56 2014
From: gunnar at hibernate.org (Gunnar Morling)
Date: Tue, 1 Apr 2014 22:55:56 +0200
Subject: [hibernate-dev] [HSEARCH] Autodiscoverable field bridges next
	steps
In-Reply-To: <81792793-F8F1-4242-86B1-BCB0349D07CE@hibernate.org>
References: <4FF34AA8-4475-48ED-91D5-7C5A7528AD70@hibernate.org>
	<81792793-F8F1-4242-86B1-BCB0349D07CE@hibernate.org>
Message-ID: <CADGJaX_z1+Jpbmgrf2VkV2HV68HiDBqEdoMsa8jeFS1ZE1vQsg@mail.gmail.com>

2014-04-01 22:19 GMT+02:00 Hardy Ferentschik <hardy at hibernate.org>:

>
> On 1 Jan 2014, at 16:36, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
>
> > ## Splitting the BridgeProvider in two methods
> >
> > A way make the inelegant code structure
> >
> >    FieldBridge bridge = provider.provide(...);
> >    if ( bridge != null ) {
> >        return bridge
> >    }
> >
> > Is to ask of the provider to answer two question:
> >
> > - boolean canProvideBridgeFor(...)
> > - FieldBridge createFieldBridge(...)
> >
> > The code would become
> >
> >    if ( provider.canProvideBridgeFor(...) ) {
> >        return createFieldBridge(...)
> >    }
>
> I prefer the latter. I tried already all sorts of arguments on the pull
> requests, but it might be that I stand alone here.
> I think it is more intuitive since it avoids the null check and I almost
> can implement the provider without looking at the Javadocs
> telling my what to do. Also in the real world, you would first ask me
> whether I can make you something, before telling me to do so, right?
>
> One of the counter arguments I've heard is, that having two methods
> instead of one creates some code duplication in the implementation.
> I find this a weak argument. If I look at the API I first look at what I
> want this API to do and how it should do it. Whether the impl needs to
> repeat
> some piece of code is a different question. And if nothing else, the
> implementation can extract the common code into a method.
>
> > Another concern is that if the answer to can... and create... are
> inconsistent, we are in trouble.
>
> Well, if canProvideBridgeFor returns true it should create the bridge when
> provide is called. Unless there is of course an (runtime) error when
> creating
> the bridge. However, this would throw an exception. If the bridge provider
> does not behave this way, you have indeed a bug, but I don't see the big
> difference
> to this type of bug to any other implementation error.
>

FWIW, I side with those preferring a single method and doing a null check.

It's mainly a matter of taste, but I feel it's easier to "forget" to invoke
the canProvide() method before calling create() than doing the null check.
I don't think a null check is something bad which should be avoided, but
it's rather the canonical idiom for dealing with option result values.

Also wouldn't create() have to do the check internally again to protect
against incorrect invocations and raise a proper exception? This would
imply a slight runtime overhead. For that reason I also prefer to access
hash maps via get() and check the result for null instead of using hasKey()
+ get().

--Hardy
>
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From sanne at hibernate.org  Tue Apr  1 21:04:36 2014
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 2 Apr 2014 02:04:36 +0100
Subject: [hibernate-dev] [HSEARCH] Autodiscoverable field bridges next
	steps
In-Reply-To: <81792793-F8F1-4242-86B1-BCB0349D07CE@hibernate.org>
References: <4FF34AA8-4475-48ED-91D5-7C5A7528AD70@hibernate.org>
	<81792793-F8F1-4242-86B1-BCB0349D07CE@hibernate.org>
Message-ID: <CAFm4XO1yFnTTTfavJ7aj3GszMBrqm84TfDzRH66m_Ncgqc34Bg@mail.gmail.com>

On 1 April 2014 21:19, Hardy Ferentschik <hardy at hibernate.org> wrote:
>
> On 1 Jan 2014, at 16:36, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
>
>> ## Splitting the BridgeProvider in two methods
>>
>> A way make the inelegant code structure
>>
>>    FieldBridge bridge = provider.provide(?);
>>    if ( bridge != null ) {
>>        return bridge
>>    }
>>
>> Is to ask of the provider to answer two question:
>>
>> - boolean canProvideBridgeFor(?)
>> - FieldBridge createFieldBridge(?)
>>
>> The code would become
>>
>>    if ( provider.canProvideBridgeFor(?) ) {
>>        return createFieldBridge(?)
>>    }
>
> I prefer the latter. I tried already all sorts of arguments on the pull requests, but it might be that I stand alone here.
> I think it is more intuitive since it avoids the null check and I almost can implement the provider without looking at the Javadocs
> telling my what to do. Also in the real world, you would first ask me whether I can make you something, before telling me to do so, right?

Lol, I'm imagining you politely asking your dog to see if he has time
to fetch your tablet :)

>
> One of the counter arguments I?ve heard is, that having two methods instead of one creates some code duplication in the implementation.
> I find this a weak argument. If I look at the API I first look at what I want this API to do and how it should do it. Whether the impl needs to repeat
> some piece of code is a different question. And if nothing else, the implementation can extract the common code into a method.
>
>> Another concern is that if the answer to can? and create? are inconsistent, we are in trouble.
>
> Well, if canProvideBridgeFor returns true it should create the bridge when provide is called. Unless there is of course an (runtime) error when creating
> the bridge. However, this would throw an exception. If the bridge provider does not behave this way, you have indeed a bug, but I don?t see the big difference
> to this type of bug to any other implementation error.

What I meant is that in certain situations the state of the
underlaying service might change between invocations. Let's say your
bridge implementor is configured via an external resource, containing
like a list of things it's supposed to handle. Now let's assume that
this can be reconfigured at runtime (crazy stuff which seems common in
OSGi world, but also not too unusual via JMX): at one moment of time,
your implementation could say "yes I can", and right after be forced
to return null or throw an exception.
True, you could classify this as an "implementation error" .. but if I
where that developer I wouldn't be sure how to fix it, while a single
method API would have been straight forward.

We might not expect these things to be configured at runtime, but we
had several examples in which things which where expected to be quite
"static" have later needed to be refactored in mutable things. If you
take the MutableSearchFactory and our complex boot, I guess you
immediatly see what kind of pain I'm referring to when we need to fix
such an assumption in a second phase.

-- Sanne

>
> ?Hardy
>
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


From steve at hibernate.org  Tue Apr  1 22:20:22 2014
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 1 Apr 2014 21:20:22 -0500
Subject: [hibernate-dev] Another @Access quandry
In-Reply-To: <CAFdSV9tc6hLP8eaK1N-+LoPLqvh9t9MyBPB9n10DbxbCeR617g@mail.gmail.com>
References: <CAFdSV9uYWpa44+GPnq37=wh8KaoWfBjeTJOS8mwiGjZi-3Nhbg@mail.gmail.com>
	<CAFm4XO0A353jt2qJGzvTRi_ExV9yUyQoc4R-VZ-hLR80EWWVfQ@mail.gmail.com>
	<20140326130216.GG42990@hibernate.org>
	<CAFdSV9tPdM8F8BseEik_4x9cWa-d1_j-0L1EEnO_-6C4aCOnzw@mail.gmail.com>
	<CAFm4XO2=ckiZau6cYspaYBz6AdXJ+JC8A1E98i6c3yGMGDBWcw@mail.gmail.com>
	<CAFdSV9sAzASQpNjy3yjNkPuyrpBHX7iSuDO5GEhOx+2r57A3cA@mail.gmail.com>
	<CAFdSV9vkjrLFDa=3qghPvNXFqmU4O8fs+asVSRtMHHei=wEd6Q@mail.gmail.com>
	<20140326162159.GK42990@hibernate.org>
	<CAFdSV9vnx9FdFhPp1PMOxAhbEtqOXNp_+oRvX3OFrL6rF+_GLw@mail.gmail.com>
	<6A185A2E-99FA-4BD5-8F35-AAF9CDA6920A@hibernate.org>
	<CAFdSV9s=QuWWDMZZG52MtqR3vZzNrSyBjUFv5JSV5WtgPGH1+A@mail.gmail.com>
	<71CD7D15-68D1-4C50-8998-B861FFB1F885@hibernate.org>
	<CAFm4XO1+otc3Kab_bKzfHqz7i3ATCRhjjYWq7cNHt0Lq41QUSA@mail.gmail.com>
	<CAFdSV9vTdTLjq7hOyz_wtiDVYrwec3sTnuSf8sthKcJNp1vSuA@mail.gmail.com>
	<CAFdSV9v+JLcnhpfnE3H5iVwtTLsKf_jQXb3-H57_GrStpUUt8Q@mail.gmail.com>
	<A1826A46-DF3D-4842-95E9-90B5CE992F79@hibernate.org>
	<CAFdSV9sPHZyJJs2FLB-mGAZCZmk1H4kpGdLfh9i8xOsxLmfMKA@mail.gmail.com>
	<BEB8A497-D4B0-4AC0-AE15-E0ED398DD75D@hibernate.org>
	<CAFdSV9tc6hLP8eaK1N-+LoPLqvh9t9MyBPB9n10DbxbCeR617g@mail.gmail.com>
Message-ID: <CAFdSV9sC_SwWpyf7=3JUvbbCPnuGZTFPEjOO=BSkwfd3GupmhA@mail.gmail.com>

I have heard no more comments, so I will move forward with this as stated
earlier.

Additionally, I started working the a PoC for the idea of making this
resolution pluggable.  Here is the initial stroke for the contract:


/**
 * Contract responsible for resolving the members that identify the
persistent
 * attributes for a given class descriptor representing a managed type.
 *
 * These members (field or method) would be where we look for mapping
annotations
 * for the attribute.
 *
 * Additionally, whether the member is a field or method would tell us the
default
 * runtime access strategy
 *
 * @author Steve Ebersole
 */
public interface PersistentAttributeMemberResolver {
/**
 * Given the ManagedType Java type descriptor and the implicit AccessType
 * to use, resolve the members that indicate persistent attributes.
 *
 * @param managedTypeDescriptor The ManagedType Java type descriptor
 * @param implicitAccessType The implicit AccessType for the resolution
 *
 * @return The list of "backing members"
 */
public List<MemberDescriptor> resolveMembers(
JavaTypeDescriptor managedTypeDescriptor,
AccessType implicitAccessType);
}



On Sun, Mar 30, 2014 at 9:51 AM, Steve Ebersole <steve at hibernate.org> wrote:

> I have pushed the latest topical guide:
> https://github.com/hibernate/hibernate-orm/blob/master/documentation/src/main/asciidoc/topical/accesstype/AccessType.adoc
>
> Thoughts?  Comments?
>
> The "Attribute-level" section is still undone, but I think the rest of the
> text lays out the expectations in that case (especially the "Extensions"
> sections) ...
>
>
>
> On Sat, Mar 29, 2014 at 2:06 PM, Hardy Ferentschik <hardy at hibernate.org>wrote:
>
>>
>> On 29 Jan 2014, at 17:59, Steve Ebersole <steve at hibernate.org> wrote:
>>
>> > Again to me this all comes down to 1 concept in JPA being used to
>> represent 3 different things.  That's never a good situation.  So maybe
>> internally we start representing all 3 distinctly.
>>
>> That's sounds like a good idea which would give us most flexibility. It
>> might create a fair bit of more work initially though.
>>
>> --Hardy
>>
>>
>>
>

From emmanuel at hibernate.org  Wed Apr  2 04:37:11 2014
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Wed, 2 Apr 2014 10:37:11 +0200
Subject: [hibernate-dev] Transcripts of the noorm meeting
Message-ID: <826B755D-F1A4-4D94-BDD3-6BADB2899709@hibernate.org>

We discussed various things

* Neo4J backend + query implementation
* bridge autodiscovery
* CI OGM instability
* Hibernate Search roadmap
* pros and cons of 2 weeks release cycles
* plans for an OGM roadmap with dates right after summit


Meeting ended Tue Apr  1 14:50:48 2014 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
Minutes:        http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2014/hibernate-dev.2014-04-01-13.50.html
Minutes (text): http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2014/hibernate-dev.2014-04-01-13.50.txt
Log:            http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2014/hibernate-dev.2014-04-01-13.50.log.html



From gunnar at hibernate.org  Wed Apr  2 05:45:30 2014
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 2 Apr 2014 11:45:30 +0200
Subject: [hibernate-dev] [OGM] Move container integration test to a
 separate default test cycle
In-Reply-To: <CANoTJYNVrTsS8Ufe36YC=ijqkhTwb_=o=936eyZMfAn784B+aw@mail.gmail.com>
References: <20140325092522.GA41254@hibernate.org>
	<CAFm4XO3ZUF2XQ3Xy_xfdsNEfRM0eOpFOORNuiaajNfbhFYsNGw@mail.gmail.com>
	<CANoTJYNVrTsS8Ufe36YC=ijqkhTwb_=o=936eyZMfAn784B+aw@mail.gmail.com>
Message-ID: <CADGJaX9-3RPfVwB1YvzFVd4YzwFTf6wSzMXpSSRyVWGYR3BX=w@mail.gmail.com>

+1 for option #1. Note that you already today can skip all integration
tests by adding -DskipITs to your Maven command.

I think it'd make sense have a single module which houses all the
integration tests which can then be executed against all possible
container/datastore combinations. By default we could run just one
combination, say ISPN on WildFly, while on CI all combinations are run via
a Matrix job (with axes being container and datastore). Starting the
servers beforehand would be a very nice improvement as well.

--Gunnar



2014-03-27 13:07 GMT+01:00 Davide D'Alto <davide at hibernate.org>:

> > My vote goes to #1 as well for the short term.
>
> +1
>
> > we need to share the running containers across
> > modules, or merge the integration tests in a single module per
> > container.
> > Not sure how far Maven will be a problem for this
>
> I think it would be easier to start and download the containers without
> using maven
> and then run the maven build assuming that everything needed is already
> downloaded and started.
>
>
>
> On Tue, Mar 25, 2014 at 11:31 AM, Sanne Grinovero <sanne at hibernate.org
> >wrote:
>
> > My vote goes to #1 as well for the short term.
> >
> > There also is a third option, which requires some more work but
> > provides a very nice balance.
> > A great deal of the slowness of this complex matrix execution can be
> > addressed to the continuous startup and teardown of services like the
> > various databases and the datastores.
> >
> > Considering that each of those services starts in less than a second,
> > the problem is not the single startup but literally the compound
> > effect of the complex matrix: if we started say MongoDB, and CouchDb,
> > and all others, and all containers at the beginning of the suite, we
> > could then run matrix tests in a very efficient way, I'd bet we could
> > keep the full matrix *and* the testsuite under a single minute. The
> > goal would be to reuse a single WildFly (or EAP) startup to test on
> > each database; i.e. we need to share the running containers across
> > modules, or merge the integration tests in a single module per
> > container.
> > Not sure how far Maven will be a problem for this.
> >
> > For the OGM needs to test on EAP, I just dicussed with Davide (same
> > office today), and since we'd be testing an old version of EAP
> > (6.1.0.Alpha1 being the latest in public Maven repositories), our idea
> > is that this is too old to be useful anyway. We'll set up a profile -
> > disabled by default - which downloads and tests latest EAP to be used
> > by the Jenkins instance running at Red Hat.
> >
> > Sanne
> >
> >
> > On 25 March 2014 09:25, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
> > > This is a follow up on
> > >
> >
> https://github.com/hibernate/hibernate-ogm/pull/307#issuecomment-38453092
> > >
> > > We keep piling up new backends, new containers to test and new rules
> > > checked at build time. A consequence is that it is becoming less and
> > > less pleasant to work on OGM.
> > >
> > > You can see that n version of Naked+WF+EAP+... multiplied by m backends
> > > simply will make this project horrendously slow to contribute to.
> > > I imagine n = 3 or 4 and m = 10 in a medium term.
> > >
> > > I see two options that would keep us around for a while:
> > >
> > > 1. Make the container integration tests only run with a specific option
> > >    activated on the CI.
> > > 2. Move the container integration tests outside in a different repo
> > >    altogether.
> > >
> > > I do prefer 1.
> > >
> > > Emmanuel
> > > _______________________________________________
> > > hibernate-dev mailing list
> > > hibernate-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From daltodavide at gmail.com  Wed Apr  2 06:01:20 2014
From: daltodavide at gmail.com (Davide D'Alto)
Date: Wed, 2 Apr 2014 11:01:20 +0100
Subject: [hibernate-dev] [OGM] CI jobs hang (Gunnar Morling)
In-Reply-To: <CADGJaX_qBLTBc7qo9GrsQvxKxEqaX_f0_A2mSjUxOK59BV5FfQ@mail.gmail.com>
References: <CAO4Yhkg+2UGP094mzH5NP5a-dN1s_6_PFvoyeymv7-6tMKiQpw@mail.gmail.com>
	<CADGJaX_qBLTBc7qo9GrsQvxKxEqaX_f0_A2mSjUxOK59BV5FfQ@mail.gmail.com>
Message-ID: <CANoTJYP3_V82=Qf8aLWQjWzHiJm353pSv8X--LC1otey4Jru6w@mail.gmail.com>

I going to update Jenkins and the plugins to see if it solves this issue.

Are there any reasons I shouldn't do this?


On Tue, Apr 1, 2014 at 2:11 PM, Gunnar Morling <gunnar at hibernate.org> wrote:

> Hi Paolo,
>
> Thanks for your reply. The thing is that these jobs used to work until
> recently, so I'm wondering which change could be causing the problem. Maybe
> a recent update to Jenkins or one of the plug-ins?
>
> Unfortunately we don't have the config audit plug-in anymore which provides
> a history at least of changes to job configs. @Davide, I think I had
> installed it once but I guess it got lost when rebuilding the instance via
> Puppet? Any chance you could add this plug-in permanently?
>
> @Paolo: Would be very interested to learn more about the Docker stuff
> you're working on once you got something :)
>
> --Gunnar
>
>
>
>
>
> 2014-04-01 15:02 GMT+02:00 Paolo Antinori <paolo.antinori at gmail.com>:
>
> > Hi Gunnar
> >
> > I am working on related activities on a replica of ci.hibernate.orgwhere
> > I
> > am playing with Docker and trying to see how well it could fit the the
> > project build needs.
> >
> > When running OGM build job on this replica server, I have noticed the
> same
> > problem.
> >
> > I think that the problem is related to Axis plugin, like you were
> pointing
> > out.
> >
> > I have also noticed this:
> >
> > http://ci.hibernate.org/job/hibernate-ogm-master/106/consoleText
> >
> > That is the link for the plain text version of the logs.
> >
> > Not sure if the message you find there:
> >
> > No such file:
> > /var/lib/jenkins/jobs/hibernate-ogm-master/builds/2014-04-01_07-01-01/log
> >
> > Is the blocking problem or just a side-effect of something else.
> >
> > I hope to be able to show soon a Docker based approach to possibly bypass
> > totally this kind of problems.
> >
> > paolo
> >
> >
> > On Tue, Apr 1, 2014 at 12:46 PM, <hibernate-dev-request at lists.jboss.org
> > >wrote:
> >
> > > Send hibernate-dev mailing list submissions to
> > >         hibernate-dev at lists.jboss.org
> > >
> > > To subscribe or unsubscribe via the World Wide Web, visit
> > >         https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > > or, via email, send a message with subject or body 'help' to
> > >         hibernate-dev-request at lists.jboss.org
> > >
> > > You can reach the person managing the list at
> > >         hibernate-dev-owner at lists.jboss.org
> > >
> > > When replying, please edit your Subject line so it is more specific
> > > than "Re: Contents of hibernate-dev digest..."
> > >
> > > Today's Topics:
> > >
> > >    1. [OGM] CI jobs hang (Gunnar Morling)
> > >    2. Re: Session and carrying 3rd party state (Gunnar Morling)
> > >    3. Re: Session and carrying 3rd party state (Gunnar Morling)
> > >
> > >
> > > ---------- Forwarded message ----------
> > > From: Gunnar Morling <gunnar at hibernate.org>
> > > To: "hibernate-dev at lists.jboss.org" <hibernate-dev at lists.jboss.org>
> > > Cc:
> > > Date: Tue, 1 Apr 2014 09:20:28 +0200
> > > Subject: [hibernate-dev] [OGM] CI jobs hang
> > > Hi,
> > >
> > > For some reason, the CI jobs for OGM can't be executed (all jobs,
> master,
> > > java8, PR seem affected) . They hang forever in an initial state, i.e.
> > > there is no console output and also the sub-jobs are not dispatched
> > (these
> > > are matrix projects). Worse, they can't even be canceled (trying to do
> so
> > > has no effect), only a server restart helps.
> > >
> > > Have there been any recent changes to the job (or server) config which
> > may
> > > cause this? I found
> > https://issues.jenkins-ci.org/browse/JENKINS-9688which
> > > indicates, that the jobs may be waiting eternally for a resource which
> > they
> > > can't acquire (I don't see any resources requested in the job config,
> > but I
> > > vaguely remember something around JGroups channels).
> > >
> > > Does anyone know what's going on here?
> > >
> > > --Gunnar
> > >
> > >
> > >
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From emmanuel at hibernate.org  Wed Apr  2 06:10:18 2014
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Wed, 2 Apr 2014 12:10:18 +0200
Subject: [hibernate-dev] [HSEARCH][Autodiscoverable] References to field
	bridges
In-Reply-To: <A0097193-2279-4D2F-8479-151DAF38E4E8@hibernate.org>
References: <4FF34AA8-4475-48ED-91D5-7C5A7528AD70@hibernate.org>
	<A0097193-2279-4D2F-8479-151DAF38E4E8@hibernate.org>
Message-ID: <1F4E8216-A0D7-4950-B0DA-FDCB91307EDE@hibernate.org>

I don?t think copying these 15 or 30 field bridges implementations is really a good thing. In the end, we will have to support them anyways in JDG if the problem is not solved at the root instead of shifted to the next lib.

On 01 Apr 2014, at 22:02, Hardy Ferentschik <hardy at hibernate.org> wrote:

> 
> On 1 Jan 2014, at 16:36, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
> 
>> ## References to field bridges
>> 
>> Despite being on an internal class, some implementations (Infinispan remove query at least) uses direct references to FieldBridge.SOME_BRIDGE.
> 
> IMO, they should not. There is a unnecessary coupling here. Easiest way for Infinispan is to use their own bridge
> 
>> I?ll reinstate them so that Sanne could integrate continuously HSearch 5 with Infinispan.
> 
> What does reinstate mean for Search 5 mean? For the next Alpha release, until Beta or even for Final. 
> 
>> I would prefer to see them go
> 
> +1 I would do it as part of this work. I don?t see a point in keeping them
> 
> ?Hardy



From emmanuel at hibernate.org  Wed Apr  2 06:16:47 2014
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Wed, 2 Apr 2014 12:16:47 +0200
Subject: [hibernate-dev] [HSEARCH] [Autodiscoverable] Implementation of
	the service loader based discovery
In-Reply-To: <7E4F5385-5C6A-4CA5-B039-C902F6D9B328@hibernate.org>
References: <4FF34AA8-4475-48ED-91D5-7C5A7528AD70@hibernate.org>
	<7E4F5385-5C6A-4CA5-B039-C902F6D9B328@hibernate.org>
Message-ID: <E8F0DB2D-F528-449D-90E0-FED8087A6079@hibernate.org>

https://hibernate.atlassian.net/browse/HSEARCH-1581

On 01 Apr 2014, at 22:24, Hardy Ferentschik <hardy at hibernate.org> wrote:

> 
> On 1 Jan 2014, at 16:36, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
> 
>> ## Implementation of the service loader based discovery
>> 
>> Hardy proposes to make each BridgeProvider a Service in the ServiceManager sense.
> 
> It is right? We allow users to provide their implementations. 
> 
>> The idea being that when we make a compatible ServiceManager OSGi wise, it will also make a compatible bridge provider discoverer.
> 
> That?s a nice side effect imo. Depending on far you want to go with OSGi, you probably want to skip at some stage Java?s ServiceLoader
> and do service lookups via OSGi mechanism. Doing Java service loading all via our ServiceManager ensures that we just have one (pluggable)
> spot in case we want to down the OSGi service route.
> 
>> It looks fine to me but as Hardy pointed out, we would need to make the ServiceManager accept several implementations per Service.
>> I?d like to separate the bridge auto-discoverability feature from that ServiceManager improvement to stay focused.
>> We can converge the service discovery as soon as the SM gains the right capability.
> 
> Do you have a separate issue for the SessionManager enhancements? 
> 
> ?Hardy
> 



From hardy at hibernate.org  Wed Apr  2 06:19:12 2014
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Wed, 2 Apr 2014 12:19:12 +0200
Subject: [hibernate-dev] [HSEARCH] Autodiscoverable field bridges next
	steps
In-Reply-To: <CADGJaX_z1+Jpbmgrf2VkV2HV68HiDBqEdoMsa8jeFS1ZE1vQsg@mail.gmail.com>
References: <4FF34AA8-4475-48ED-91D5-7C5A7528AD70@hibernate.org>
	<81792793-F8F1-4242-86B1-BCB0349D07CE@hibernate.org>
	<CADGJaX_z1+Jpbmgrf2VkV2HV68HiDBqEdoMsa8jeFS1ZE1vQsg@mail.gmail.com>
Message-ID: <FFD07E63-BDD6-442B-B603-22E5BEE87082@hibernate.org>


On 1 Jan 2014, at 22:55, Gunnar Morling <gunnar at hibernate.org> wrote:

> 2014-04-01 22:19 GMT+02:00 Hardy Ferentschik <hardy at hibernate.org>:
> 
> On 1 Jan 2014, at 16:36, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
> 
> > ## Splitting the BridgeProvider in two methods
> 
> 
> FWIW, I side with those preferring a single method and doing a null check.
> 
> It's mainly a matter of taste,

Sure, to a certain degree

> but I feel it's easier to "forget" to invoke the canProvide() method before calling create() than doing the null check.

But you don?t have to do it. If you as user want to provide a custom BridgeProvider you just implement the interface.
It is up to us to make the right calls. What?s about a custom ConstraintValidator in Bean Validation where you have initialise 
ans isValid? The user does not need to call these methods himself and he cannot forget to call initialise. Ensuring the right
order of calls is part of the Validator engine.

For me also Iterator#hasNext() and #next() comes to mind. Also a lot of  Lucene interfaces you can implement,
for example Collector or FieldComparator, have a very intricate interaction between the Lucene engine and 
the implementor of the interface.  

> I don't think a null check is something bad which should be avoided,

sure you can do that, but you can also be more explicit.

> Also wouldn't create() have to do the check internally again to protect against incorrect invocations and raise a proper exception?

It could, but it is not a requirement.

> This would imply a slight runtime overhead.

I don?t think this is an issue here. Bridge discovery is a bootstrapping thing which happens once during the buildup of the SearchFactory.

Anyways, I guess I rest my case.

?Hardy

From hardy at hibernate.org  Wed Apr  2 06:23:14 2014
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Wed, 2 Apr 2014 12:23:14 +0200
Subject: [hibernate-dev] [HSEARCH] Autodiscoverable field bridges next
	steps
In-Reply-To: <CAFm4XO1yFnTTTfavJ7aj3GszMBrqm84TfDzRH66m_Ncgqc34Bg@mail.gmail.com>
References: <4FF34AA8-4475-48ED-91D5-7C5A7528AD70@hibernate.org>
	<81792793-F8F1-4242-86B1-BCB0349D07CE@hibernate.org>
	<CAFm4XO1yFnTTTfavJ7aj3GszMBrqm84TfDzRH66m_Ncgqc34Bg@mail.gmail.com>
Message-ID: <B9F13346-2C5E-4B6B-9CD6-708788931026@hibernate.org>


On 2 Jan 2014, at 03:04, Sanne Grinovero <sanne at hibernate.org> wrote:

> On 1 April 2014 21:19, Hardy Ferentschik <hardy at hibernate.org> wrote:
>> 
>> On 1 Jan 2014, at 16:36, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
>> 
>>> ## Splitting the BridgeProvider in two methods
>>> 
>>> A way make the inelegant code structure
>>> 
>>>   FieldBridge bridge = provider.provide(?);
>>>   if ( bridge != null ) {
>>>       return bridge
>>>   }
>>> 
>>> Is to ask of the provider to answer two question:
>>> 
>>> - boolean canProvideBridgeFor(?)
>>> - FieldBridge createFieldBridge(?)
>>> 
>>> The code would become
>>> 
>>>   if ( provider.canProvideBridgeFor(?) ) {
>>>       return createFieldBridge(?)
>>>   }
>> 
>> I prefer the latter. I tried already all sorts of arguments on the pull requests, but it might be that I stand alone here.
>> I think it is more intuitive since it avoids the null check and I almost can implement the provider without looking at the Javadocs
>> telling my what to do. Also in the real world, you would first ask me whether I can make you something, before telling me to do so, right?
> 
> Lol, I'm imagining you politely asking your dog to see if he has time
> to fetch your tablet :)

Different story. If I know she can do certain things, I just give her the command. Different pattern.

>> One of the counter arguments I?ve heard is, that having two methods instead of one creates some code duplication in the implementation.
>> I find this a weak argument. If I look at the API I first look at what I want this API to do and how it should do it. Whether the impl needs to repeat
>> some piece of code is a different question. And if nothing else, the implementation can extract the common code into a method.
>> 
>>> Another concern is that if the answer to can? and create? are inconsistent, we are in trouble.
>> 
>> Well, if canProvideBridgeFor returns true it should create the bridge when provide is called. Unless there is of course an (runtime) error when creating
>> the bridge. However, this would throw an exception. If the bridge provider does not behave this way, you have indeed a bug, but I don?t see the big difference
>> to this type of bug to any other implementation error.
> 
> What I meant is that in certain situations the state of the
> underlaying service might change between invocations. Let's say your
> bridge implementor is configured via an external resource, containing
> like a list of things it's supposed to handle. Now let's assume that
> this can be reconfigured at runtime (crazy stuff which seems common in
> OSGi world, but also not too unusual via JMX): at one moment of time,
> your implementation could say "yes I can", and right after be forced
> to return null or throw an exception.

This sounds ways to o construed to me to even be worth considering.

> We might not expect these things to be configured at runtime, but we
> had several examples in which things which where expected to be quite
> "static" have later needed to be refactored in mutable things. If you
> take the MutableSearchFactory and our complex boot, I guess you
> immediatly see what kind of pain I'm referring to when we need to fix
> such an assumption in a second phase.

The pain of MutableSearchFactory is not so much the fact that we need to be able
to modify a SearchFactory, but that somewhere we went a bit overboard when implementing it.
I don?t see any connection between MutableSearchFactory and BridgeProvider whatsoever.

?Hardy

From hardy at hibernate.org  Wed Apr  2 06:26:44 2014
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Wed, 2 Apr 2014 12:26:44 +0200
Subject: [hibernate-dev] [HSEARCH][Autodiscoverable] References to field
	bridges
In-Reply-To: <1F4E8216-A0D7-4950-B0DA-FDCB91307EDE@hibernate.org>
References: <4FF34AA8-4475-48ED-91D5-7C5A7528AD70@hibernate.org>
	<A0097193-2279-4D2F-8479-151DAF38E4E8@hibernate.org>
	<1F4E8216-A0D7-4950-B0DA-FDCB91307EDE@hibernate.org>
Message-ID: <13A450D1-CBA8-4B15-ABEB-7D9166C63C1F@hibernate.org>


On 2 Jan 2014, at 12:10, Emmanuel Bernard <emmanuel at hibernate.org> wrote:

> I don?t think copying these 15 or 30 field bridges implementations is really a good thing. In the end, we will have to support them anyways in JDG if the problem is not solved at the root instead of shifted to the next lib.

My understanding was that only a couple of bridges are referenced directly. Should in the most common case our bridge discovery work?

?Hardy 

> On 01 Apr 2014, at 22:02, Hardy Ferentschik <hardy at hibernate.org> wrote:
> 
>> 
>> On 1 Jan 2014, at 16:36, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
>> 
>>> ## References to field bridges
>>> 
>>> Despite being on an internal class, some implementations (Infinispan remove query at least) uses direct references to FieldBridge.SOME_BRIDGE.
>> 
>> IMO, they should not. There is a unnecessary coupling here. Easiest way for Infinispan is to use their own bridge
>> 
>>> I?ll reinstate them so that Sanne could integrate continuously HSearch 5 with Infinispan.
>> 
>> What does reinstate mean for Search 5 mean? For the next Alpha release, until Beta or even for Final. 
>> 
>>> I would prefer to see them go
>> 
>> +1 I would do it as part of this work. I don?t see a point in keeping them
>> 
>> ?Hardy
> 



From hardy at hibernate.org  Wed Apr  2 07:23:26 2014
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Wed, 2 Apr 2014 13:23:26 +0200
Subject: [hibernate-dev] [HSEARCH] Autodiscoverable field bridges next
	steps
In-Reply-To: <D6A3D1B3-1509-4CC8-B630-E3CB4A5FE841@hibernate.org>
References: <4FF34AA8-4475-48ED-91D5-7C5A7528AD70@hibernate.org>
	<D6A3D1B3-1509-4CC8-B630-E3CB4A5FE841@hibernate.org>
Message-ID: <BDB0B75C-7765-4A26-A042-E33DC2C7E007@hibernate.org>


On 1 Jan 2014, at 22:07, Hardy Ferentschik <hardy at hibernate.org> wrote:

> 
> On 1 Jan 2014, at 16:36, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
> 
>> ## Handling duplicates
>> 
>> I had in mind the following logic.
>> 
>> Prevent custom bridge providers to offer bridges in the same situation.

I am still trying to wrap my head around ?same situation?. It might help to list the different cases we have. Also the POC
for BridgeProvider has this method:

    FieldBridge returnFieldBridgeIfMatching(Class<?> returnType, AnnotatedElement bridgedElement, String memberName, ServiceManager serviceManager);

1) Explicit field bridge declaration 

@Indexed
class Foo {
    @Field(bridge=@FieldBridge(impl=MyCustomBridge.class)
    String foo;

    @Field
    @FieldBridge(impl=MyOtherCustomBridge.class)
    String snafu;

    // ...
}

These is the simple case. BridgeProvider is not even involved, since the bridge is explicitly specified

2) Bridge is indirectly specified via its context 

2a) @TikaBridge

@Indexed
class Foo {
	@Lob
	@Basic(fetch = FetchType.LAZY)
	@Field
	@TikaBridge
	Blob content;

        //...
}

2b) @Spatial

@Indexed
class Bar {
	@Spatial
	public Coordinates getLocation() {
		return new Coordinates() {
			@Override
			public Double getLatitude() {
				return latitude;
			}

			@Override
			public Double getLongitude() {
				return longitude;
			}
		};
	}
}

2c) Some custom annotation 

@Indexed
class Foo {
    @Field
    String foo;

    @Field
    @Snafu
    String snafu;

    // ?
}

A couple of considerations here. I guess 2a and 2b are the driving force behind passing the AnnotatedElement into the BridgeProvider contract. The current implementations would check whether 
an annotation like @TikaBridge or @Spatal exist and behave accordingly. Part of the problem is that in the case of programmatic configuration we now have to create a pseudo annotated element 
to make this contract work (see related discussion). This works fine with the current commons-annotations approach, but the aim is really to let the programmatic configuration populate the internal
metamodel directly instead of creating pseudo annotations. 

The question for me atm, is why we go via the BridgeProvider at all for 2a and 2b? The bridge might not be explicitly specified via a @Bridge annotation, but it is still a clear case due to
@TikaBridge and @Spatial. Why can not the AnnotationMetadataProvider take care of this and during the processing of the annotations of a property act accordingly. A programmatic metadata provider 
would also just act depending on whether spatial() was specified or not.

The problem maybe starts already at BridgeFactory#guessType which gets also passed (numeric) field  annotations as well as the processed member. guessType does then two things, it processes the 
annotations and if potentially queries the BridgeProviders. I think parts of the responsibility should be moved into AnnotationMetadataProvider. BridgeFactory#guessType should really only be called in
the case where the bridge is not explicitly or implicitly specified.

Which leaves 2c. The question is whether we think it is a valid use case to have a BridgeProvider which returns a different bridge depending on some non Search related annotation (@Snafu). If so,
we indeed need to pass the AnnotatedElement into the BridgeProvider.

3) No explicit or implicit bridge config

@Indexed
class Foo {
    @Field
    String snafu;

    // ?
}

I guess this is main use case for the BridgeProvider, right? In this case the bridge really depends on the type of the indexed property (in the worst case also on some additional custom annotation if
we support 2c).


Thoughts?

?Hardy 



From hardy at hibernate.org  Wed Apr  2 07:34:26 2014
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Wed, 2 Apr 2014 13:34:26 +0200
Subject: [hibernate-dev] Another @Access quandry
In-Reply-To: <CAFdSV9sC_SwWpyf7=3JUvbbCPnuGZTFPEjOO=BSkwfd3GupmhA@mail.gmail.com>
References: <CAFdSV9uYWpa44+GPnq37=wh8KaoWfBjeTJOS8mwiGjZi-3Nhbg@mail.gmail.com>
	<CAFm4XO0A353jt2qJGzvTRi_ExV9yUyQoc4R-VZ-hLR80EWWVfQ@mail.gmail.com>
	<20140326130216.GG42990@hibernate.org>
	<CAFdSV9tPdM8F8BseEik_4x9cWa-d1_j-0L1EEnO_-6C4aCOnzw@mail.gmail.com>
	<CAFm4XO2=ckiZau6cYspaYBz6AdXJ+JC8A1E98i6c3yGMGDBWcw@mail.gmail.com>
	<CAFdSV9sAzASQpNjy3yjNkPuyrpBHX7iSuDO5GEhOx+2r57A3cA@mail.gmail.com>
	<CAFdSV9vkjrLFDa=3qghPvNXFqmU4O8fs+asVSRtMHHei=wEd6Q@mail.gmail.com>
	<20140326162159.GK42990@hibernate.org>
	<CAFdSV9vnx9FdFhPp1PMOxAhbEtqOXNp_+oRvX3OFrL6rF+_GLw@mail.gmail.com>
	<6A185A2E-99FA-4BD5-8F35-AAF9CDA6920A@hibernate.org>
	<CAFdSV9s=QuWWDMZZG52MtqR3vZzNrSyBjUFv5JSV5WtgPGH1+A@mail.gmail.com>
	<71CD7D15-68D1-4C50-8998-B861FFB1F885@hibernate.org>
	<CAFm4XO1+otc3Kab_bKzfHqz7i3ATCRhjjYWq7cNHt0Lq41QUSA@mail.gmail.com>
	<CAFdSV9vTdTLjq7hOyz_wtiDVYrwec3sTnuSf8sthKcJNp1vSuA@mail.gmail.com>
	<CAFdSV9v+JLcnhpfnE3H5iVwtTLsKf_jQXb3-H57_GrStpUUt8Q@mail.gmail.com>
	<A1826A46-DF3D-4842-95E9-90B5CE992F79@hibernate.org>
	<CAFdSV9sPHZyJJs2FLB-mGAZCZmk1H4kpGdLfh9i8xOsxLmfMKA@mail.gmail.com>
	<BEB8A497-D4B0-4AC0-AE15-E0ED398DD75D@hibernate.org>
	<CAFdSV9tc6hLP8eaK1N-+LoPLqvh9t9MyBPB9n10DbxbCeR617g@mail.gmail.com>
	<CAFdSV9sC_SwWpyf7=3JUvbbCPnuGZTFPEjOO=BSkwfd3GupmhA@mail.gmail.com>
Message-ID: <846D64E4-95EA-468E-A887-A3462510EF07@hibernate.org>


On 2 Jan 2014, at 04:20, Steve Ebersole <steve at hibernate.org> wrote:

> I have heard no more comments, so I will move forward with this as stated earlier.

Sorry for the late reply. I had a read through and what you describe is what I would expect (in fact I hope
I basically implemented it this way on the metamodel branch).

There is a typo in example 4:

@Entity
@Access(PROPERTY)
public class PublishedDocument extends Document 

Should be @Access(FIELD)


> Additionally, I started working the a PoC for the idea of making this resolution pluggable.  Here is the initial stroke for the contract:
> 
> 
> /**
>  * Contract responsible for resolving the members that identify the persistent 
>  * attributes for a given class descriptor representing a managed type.
>  * 
>  * These members (field or method) would be where we look for mapping annotations 
>  * for the attribute.
>  * 
>  * Additionally, whether the member is a field or method would tell us the default
>  * runtime access strategy
>  *
>  * @author Steve Ebersole
>  */
> public interface PersistentAttributeMemberResolver {
> 	/**
> 	 * Given the ManagedType Java type descriptor and the implicit AccessType
> 	 * to use, resolve the members that indicate persistent attributes.
> 	 * 
> 	 * @param managedTypeDescriptor The ManagedType Java type descriptor
> 	 * @param implicitAccessType The implicit AccessType for the resolution
> 	 * 
> 	 * @return The list of "backing members"
> 	 */
> 	public List<MemberDescriptor> resolveMembers(
> 			JavaTypeDescriptor managedTypeDescriptor, 
> 			AccessType implicitAccessType);
> }


Where MemberDescriptor and JavaTypeDescriptor are the descriptors from the new reflite layer, right?
This should work.

?Hardy

From gunnar at hibernate.org  Wed Apr  2 10:25:28 2014
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 2 Apr 2014 16:25:28 +0200
Subject: [hibernate-dev] [OGM] OGM and Bean Validation
Message-ID: <CADGJaX8gQiy6rPii0EvkU-8L28WR97QC+pzgdjLMdHyQCyDQmQ@mail.gmail.com>

Hi,

Working on a demo for OGM, I tried to apply Bean Validation constraints to
my entities and have them automatically validated during the persistence
lifecycle.

This works as expected (which is very nice), the only thing which made me
wonder is that the resulting ConstraintViolationException is wrapped into a
RollbackException. Basically that's not surprising as we use TX demarcation
to control the flush cycle also if the store is actually non-transactional,
yet it may cause irritations and false expectations by users.

So I'm wondering whether we rather should raise a more generic
PersistenceException (or another specialized type which doesn't indicate a
rollback may happen) when using a non-transactional backend? What do you
think?

--Gunnar

From emmanuel at hibernate.org  Wed Apr  2 06:16:47 2014
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Wed, 2 Apr 2014 12:16:47 +0200
Subject: [hibernate-dev] [HSEARCH] [Autodiscoverable] Implementation of
	the service loader based discovery
In-Reply-To: <7E4F5385-5C6A-4CA5-B039-C902F6D9B328@hibernate.org>
References: <4FF34AA8-4475-48ED-91D5-7C5A7528AD70@hibernate.org>
	<7E4F5385-5C6A-4CA5-B039-C902F6D9B328@hibernate.org>
Message-ID: <E8F0DB2D-F528-449D-90E0-FED8087A6079@hibernate.org>

https://hibernate.atlassian.net/browse/HSEARCH-1581

On 01 Apr 2014, at 22:24, Hardy Ferentschik <hardy at hibernate.org> wrote:

> 
> On 1 Jan 2014, at 16:36, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
> 
>> ## Implementation of the service loader based discovery
>> 
>> Hardy proposes to make each BridgeProvider a Service in the ServiceManager sense.
> 
> It is right? We allow users to provide their implementations. 
> 
>> The idea being that when we make a compatible ServiceManager OSGi wise, it will also make a compatible bridge provider discoverer.
> 
> That?s a nice side effect imo. Depending on far you want to go with OSGi, you probably want to skip at some stage Java?s ServiceLoader
> and do service lookups via OSGi mechanism. Doing Java service loading all via our ServiceManager ensures that we just have one (pluggable)
> spot in case we want to down the OSGi service route.
> 
>> It looks fine to me but as Hardy pointed out, we would need to make the ServiceManager accept several implementations per Service.
>> I?d like to separate the bridge auto-discoverability feature from that ServiceManager improvement to stay focused.
>> We can converge the service discovery as soon as the SM gains the right capability.
> 
> Do you have a separate issue for the SessionManager enhancements? 
> 
> ?Hardy
> 



From emmanuel at hibernate.org  Wed Apr  2 06:21:09 2014
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Wed, 2 Apr 2014 12:21:09 +0200
Subject: [hibernate-dev] [HSEARCH] [Autodiscoverable] Splitting the
	BridgeProvider in two methods
In-Reply-To: <81792793-F8F1-4242-86B1-BCB0349D07CE@hibernate.org>
References: <4FF34AA8-4475-48ED-91D5-7C5A7528AD70@hibernate.org>
	<81792793-F8F1-4242-86B1-BCB0349D07CE@hibernate.org>
Message-ID: <46B11812-3267-4CA0-A327-088C83893F46@hibernate.org>


On 01 Apr 2014, at 22:19, Hardy Ferentschik <hardy at hibernate.org> wrote:

> Also in the real world, you would first ask me whether I can make you something, before telling me to do so, right?

Well in real life I guess you get all kinds of design.

- directly tell someone to do it and complain if that?s not done
- directly tell someone to do it and complain even if that?s done
- ask and if the answer is positive tell someone to do it
- ask and tell someone to do it in an atomic fashion ; expecting a no
- ask in a rhetorical fashion and tell someone to do it regardless

Our problem is much simpler to design ;)

From emmanuel at hibernate.org  Wed Apr  2 07:30:14 2014
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Wed, 2 Apr 2014 13:30:14 +0200
Subject: [hibernate-dev] [HSEARCH] [Autodiscoverable] Splitting the
	BridgeProvider in two methods
In-Reply-To: <CAFm4XO1yFnTTTfavJ7aj3GszMBrqm84TfDzRH66m_Ncgqc34Bg@mail.gmail.com>
References: <4FF34AA8-4475-48ED-91D5-7C5A7528AD70@hibernate.org>
	<81792793-F8F1-4242-86B1-BCB0349D07CE@hibernate.org>
	<CAFm4XO1yFnTTTfavJ7aj3GszMBrqm84TfDzRH66m_Ncgqc34Bg@mail.gmail.com>
Message-ID: <D2E64362-7615-495E-B8AF-9DADA6F6EC74@hibernate.org>


On 02 Apr 2014, at 03:04, Sanne Grinovero <sanne at hibernate.org> wrote:
>>> Another concern is that if the answer to can? and create? are inconsistent, we are in trouble.
>> 
>> Well, if canProvideBridgeFor returns true it should create the bridge when provide is called. Unless there is of course an (runtime) error when creating
>> the bridge. However, this would throw an exception. If the bridge provider does not behave this way, you have indeed a bug, but I don?t see the big difference
>> to this type of bug to any other implementation error.
> 
> What I meant is that in certain situations the state of the
> underlaying service might change between invocations. Let's say your
> bridge implementor is configured via an external resource, containing
> like a list of things it's supposed to handle. Now let's assume that
> this can be reconfigured at runtime (crazy stuff which seems common in
> OSGi world, but also not too unusual via JMX): at one moment of time,
> your implementation could say "yes I can", and right after be forced
> to return null or throw an exception.
> True, you could classify this as an "implementation error" .. but if I
> where that developer I wouldn't be sure how to fix it, while a single
> method API would have been straight forward.
> 
> We might not expect these things to be configured at runtime, but we
> had several examples in which things which where expected to be quite
> "static" have later needed to be refactored in mutable things. If you
> take the MutableSearchFactory and our complex boot, I guess you
> immediatly see what kind of pain I'm referring to when we need to fix
> such an assumption in a second phase.


I don?t think you argument is relevant in this situation.
The situation you describe would also mean that we should guessType every time we need a bridge rather than onces at startup. It would also mean that because of the shape of the moon the application would boot or fail (see duplication logic). In other wiords, having two methods would be the least of our problems :)

From emmanuel at hibernate.org  Wed Apr  2 08:30:41 2014
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Wed, 2 Apr 2014 14:30:41 +0200
Subject: [hibernate-dev] [HSEARCH] [Autodiscoverable] Handling duplicates
In-Reply-To: <D6A3D1B3-1509-4CC8-B630-E3CB4A5FE841@hibernate.org>
References: <4FF34AA8-4475-48ED-91D5-7C5A7528AD70@hibernate.org>
	<D6A3D1B3-1509-4CC8-B630-E3CB4A5FE841@hibernate.org>
Message-ID: <4715DF5F-B6AF-4BB2-8457-008F69856CCA@hibernate.org>


On 01 Apr 2014, at 22:07, Hardy Ferentschik <hardy at hibernate.org> wrote:

> 
> On 1 Jan 2014, at 16:36, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
> 
>> ## Handling duplicates
>> 
>> I had in mind the following logic.
>> 
>> Prevent custom bridge providers to offer bridges in the same situation.
> 
> What do you mean with "in the same situation?? You mean there cannot be two bridge providers for the same return type (assuming no dedicated bridge annotation)

I mean for the same set of parameters passed to BridgeFactory.guessType(?).

> 
>> That would be an error at start up time as the alternative of picking up one of them does not seem very attractive.
> 
> How do you determine bridge providers providing bridges for the ?same situation??

More than one BridgeProvider.returnFieldBridgeIfMatching (or canProvideFieldBridge()) returns a field bridge instance.

> 
>> Sanne questioned the idea of built-in bridge and would rather have all bridges handled equally and not allow duplication.
>> It seems that the current set of bridges cannot support that approach. When I developed the code, I realised that there is an ordering to respect. If I put the TikeBridgeProvider logic before the date and calendar bridgeProviders, then the DSLTest fails. I could not find why but it shows that we have some interdependencies at the moment.
> 
> I think it would be a good idea to fine out what?s going on first.

So the TikaBridge problem was due to a test placing @TikaBridge on a Date (`@TikaBridge Date someDate`)

- If @TikaBridge is placed on an unknown type, the bridge fails and the test checks that.
- if the DateBridgeProvider runs before the TikeBridgeProvider then the exception does not happen as the DataBridgeProvider not only checks for `@DateBridge` but also for naked `Date` return type and wins over tike bridge.

## Option A

We could force all discoverable bridges to only handle bridges with an explicit annotation e.g. `@MyBridge SomeType`. And handle the non annotated types in the last phase of the BridgeFactory.guessType but a few questions arise:

- can an BridgeProvider accepting annotated types override the bridges that would be provided by the non annotated type logic at the bottom of guessType?
- if yes, how is that significantly different than my initial ordering proposal
- is it acceptable to impose to annotate all members receiving a BridgeProvider?s bridge? That seems to go against the idea of autodiscoverable bridges as `@MyBridge` is not significantly different than `@FieldBridge(implMyFB.class)`

## Option B

An alternative is to impose that only a single BridgeProvider could answer for a given return type.

## Option C

My gut feeling is that it?s a bit too restrictive and I?d prefer to allow:

- user provided BridgeProvider to override the core BridgeProviders
- raise an exception if two user provided bridge providers answer for the same guessType(?) call.

It offers more flexibility, like the ability to qualify a type with an annotation to discriminate which bridge is expected. But that raises the question of the naked types (i.e. no annotated). To answer that problem we either:

- not allow the mix of naked types and annotated types (by two different providers)
- allow it but have two methods on BridgeProvider. One for annotated types (qualified) and one for naked types. We could run the latter phase after the former phase and only complain if two bridge providers react for a single phase.

I?m fine with starting with option B but latter moving to option C will break backward compatibility. So in the end the question is what do you mean precisely by "Allow loading of additional "built-in bridges" via autodiscovery?.

Thoughts?

From emmanuel at hibernate.org  Wed Apr  2 11:02:02 2014
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Wed, 2 Apr 2014 17:02:02 +0200
Subject: [hibernate-dev] [HSEARCH] [Autodiscoverable] Implementation of
	the service loader based discovery
In-Reply-To: <7E4F5385-5C6A-4CA5-B039-C902F6D9B328@hibernate.org>
References: <4FF34AA8-4475-48ED-91D5-7C5A7528AD70@hibernate.org>
	<7E4F5385-5C6A-4CA5-B039-C902F6D9B328@hibernate.org>
Message-ID: <F1C85E10-8549-43F7-B853-6A03128CF70D@hibernate.org>

https://hibernate.atlassian.net/browse/HSEARCH-1581

On 01 Apr 2014, at 22:24, Hardy Ferentschik <hardy at hibernate.org> wrote:

> 
> On 1 Jan 2014, at 16:36, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
> 
>> ## Implementation of the service loader based discovery
>> 
>> Hardy proposes to make each BridgeProvider a Service in the ServiceManager sense.
> 
> It is right? We allow users to provide their implementations. 
> 
>> The idea being that when we make a compatible ServiceManager OSGi wise, it will also make a compatible bridge provider discoverer.
> 
> That?s a nice side effect imo. Depending on far you want to go with OSGi, you probably want to skip at some stage Java?s ServiceLoader
> and do service lookups via OSGi mechanism. Doing Java service loading all via our ServiceManager ensures that we just have one (pluggable)
> spot in case we want to down the OSGi service route.
> 
>> It looks fine to me but as Hardy pointed out, we would need to make the ServiceManager accept several implementations per Service.
>> I?d like to separate the bridge auto-discoverability feature from that ServiceManager improvement to stay focused.
>> We can converge the service discovery as soon as the SM gains the right capability.
> 
> Do you have a separate issue for the SessionManager enhancements? 
> 
> ?Hardy
> 



From emmanuel at hibernate.org  Wed Apr  2 11:08:59 2014
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Wed, 2 Apr 2014 17:08:59 +0200
Subject: [hibernate-dev] [HSEARCH] [Autodiscoverable] AnnotatedElement
In-Reply-To: <37838A2C-BE3F-4CD2-92AB-2A31F4756C2D@hibernate.org>
References: <4FF34AA8-4475-48ED-91D5-7C5A7528AD70@hibernate.org>
	<37838A2C-BE3F-4CD2-92AB-2A31F4756C2D@hibernate.org>
Message-ID: <24B4C4E1-904F-48F1-9E71-7B72DA417730@hibernate.org>


On 01 Apr 2014, at 22:20, Hardy Ferentschik <hardy at hibernate.org> wrote:

> 
> On 1 Jan 2014, at 16:36, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
> 
>> ## AnnotatedElement
>> 
>> Hardy does not like us being tied to the actual physical annotation objects. I tend to agree with him as we would need to fake it for free-form entities.
>> Since he worked on Jandex and the ORM side of parsing, he will work on a proposal that abstracts us away from AnnotatedElement.
>> The alternative is to pass the XLayer objects but not everyone is fine of that abstraction.
> 
> +1 Need to think a bit about it.
> 

https://hibernate.atlassian.net/browse/HSEARCH-1582

From brmeyer at redhat.com  Wed Apr  2 11:30:06 2014
From: brmeyer at redhat.com (Brett Meyer)
Date: Wed, 2 Apr 2014 11:30:06 -0400 (EDT)
Subject: [hibernate-dev] Hibernate ORM 4.3.5.Final Released
Message-ID: <2096589812.6298999.1396452606020.JavaMail.zimbra@redhat.com>

http://in.relation.to/Bloggers/HibernateORM435FinalReleased

Brett Meyer
Red Hat, Hibernate ORM


From emmanuel at hibernate.org  Wed Apr  2 11:37:42 2014
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Wed, 2 Apr 2014 17:37:42 +0200
Subject: [hibernate-dev] [HSEARCH] Autodiscoverable field bridges next
	steps
In-Reply-To: <BDB0B75C-7765-4A26-A042-E33DC2C7E007@hibernate.org>
References: <4FF34AA8-4475-48ED-91D5-7C5A7528AD70@hibernate.org>
	<D6A3D1B3-1509-4CC8-B630-E3CB4A5FE841@hibernate.org>
	<BDB0B75C-7765-4A26-A042-E33DC2C7E007@hibernate.org>
Message-ID: <68D0A63C-2D53-4E91-B5B7-33D7845AD1C1@hibernate.org>

Yes your analysis is correct.
I would clarify that 3 or 2c don?t have to apply on already supported return types, it is more likely custom types like JodaTime types.

I do think 3 is the most valuable but that 2c is a relatively close second.

Now the @Spatial and @TikaBridge annotations do have attributes which will influence how the underlying bridge is created.
I don?t think you are proposing to move the spatial and Tika bridge creation up on AnnotationMetadataProvider. That would AFAIU duplicate the bridge creation logic between the AMP and some ProgrammaticMetadataProvider.
Also I have a hard time navigating and understanding AnnotationMetadataProvider, so I?m not sure we should make it more complex.

So somehow, the AMP should convert @Spatial, @NumericField, @TikaBridge, and @DateBridge into some non annotation based representation and pass that information to the bridgeFactory. Your approach would be to call explicitly buildXxxBridge() - like buildDateBridge() - methods form AMP. These would be hosted on the BridgeFactory. Is that correct? And the same explicit call logic would be done on a programmatic API equivalent.

Now how would you pass and to these kind of explicit calls in the 2c case when the annotation is unknown a priori?

On 02 Apr 2014, at 13:23, Hardy Ferentschik <hardy at hibernate.org> wrote:

> 
> On 1 Jan 2014, at 22:07, Hardy Ferentschik <hardy at hibernate.org> wrote:
> 
>> 
>> On 1 Jan 2014, at 16:36, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
>> 
>>> ## Handling duplicates
>>> 
>>> I had in mind the following logic.
>>> 
>>> Prevent custom bridge providers to offer bridges in the same situation.
> 
> I am still trying to wrap my head around ?same situation?. It might help to list the different cases we have. Also the POC
> for BridgeProvider has this method:
> 
>    FieldBridge returnFieldBridgeIfMatching(Class<?> returnType, AnnotatedElement bridgedElement, String memberName, ServiceManager serviceManager);
> 
> 1) Explicit field bridge declaration 
> 
> @Indexed
> class Foo {
>    @Field(bridge=@FieldBridge(impl=MyCustomBridge.class)
>    String foo;
> 
>    @Field
>    @FieldBridge(impl=MyOtherCustomBridge.class)
>    String snafu;
> 
>    // ...
> }
> 
> These is the simple case. BridgeProvider is not even involved, since the bridge is explicitly specified
> 
> 2) Bridge is indirectly specified via its context 
> 
> 2a) @TikaBridge
> 
> @Indexed
> class Foo {
> 	@Lob
> 	@Basic(fetch = FetchType.LAZY)
> 	@Field
> 	@TikaBridge
> 	Blob content;
> 
>        //...
> }
> 
> 2b) @Spatial
> 
> @Indexed
> class Bar {
> 	@Spatial
> 	public Coordinates getLocation() {
> 		return new Coordinates() {
> 			@Override
> 			public Double getLatitude() {
> 				return latitude;
> 			}
> 
> 			@Override
> 			public Double getLongitude() {
> 				return longitude;
> 			}
> 		};
> 	}
> }
> 
> 2c) Some custom annotation 
> 
> @Indexed
> class Foo {
>    @Field
>    String foo;
> 
>    @Field
>    @Snafu
>    String snafu;
> 
>    // ?
> }
> 
> A couple of considerations here. I guess 2a and 2b are the driving force behind passing the AnnotatedElement into the BridgeProvider contract. The current implementations would check whether 
> an annotation like @TikaBridge or @Spatal exist and behave accordingly. Part of the problem is that in the case of programmatic configuration we now have to create a pseudo annotated element 
> to make this contract work (see related discussion). This works fine with the current commons-annotations approach, but the aim is really to let the programmatic configuration populate the internal
> metamodel directly instead of creating pseudo annotations. 
> 
> The question for me atm, is why we go via the BridgeProvider at all for 2a and 2b? The bridge might not be explicitly specified via a @Bridge annotation, but it is still a clear case due to
> @TikaBridge and @Spatial. Why can not the AnnotationMetadataProvider take care of this and during the processing of the annotations of a property act accordingly. A programmatic metadata provider 
> would also just act depending on whether spatial() was specified or not.
> 
> The problem maybe starts already at BridgeFactory#guessType which gets also passed (numeric) field  annotations as well as the processed member. guessType does then two things, it processes the 
> annotations and if potentially queries the BridgeProviders. I think parts of the responsibility should be moved into AnnotationMetadataProvider. BridgeFactory#guessType should really only be called in
> the case where the bridge is not explicitly or implicitly specified.
> 
> Which leaves 2c. The question is whether we think it is a valid use case to have a BridgeProvider which returns a different bridge depending on some non Search related annotation (@Snafu). If so,
> we indeed need to pass the AnnotatedElement into the BridgeProvider.
> 
> 3) No explicit or implicit bridge config
> 
> @Indexed
> class Foo {
>    @Field
>    String snafu;
> 
>    // ?
> }
> 
> I guess this is main use case for the BridgeProvider, right? In this case the bridge really depends on the type of the indexed property (in the worst case also on some additional custom annotation if
> we support 2c).
> 
> 
> Thoughts?
> 
> ?Hardy 
> 



From emmanuel at hibernate.org  Wed Apr  2 11:40:16 2014
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Wed, 2 Apr 2014 17:40:16 +0200
Subject: [hibernate-dev] [OGM] OGM and Bean Validation
In-Reply-To: <CADGJaX8gQiy6rPii0EvkU-8L28WR97QC+pzgdjLMdHyQCyDQmQ@mail.gmail.com>
References: <CADGJaX8gQiy6rPii0EvkU-8L28WR97QC+pzgdjLMdHyQCyDQmQ@mail.gmail.com>
Message-ID: <AE122720-E881-4112-85B4-09E1A6A6978D@hibernate.org>

This would go against the JPA spec unfortunately.

On 02 Apr 2014, at 16:25, Gunnar Morling <gunnar at hibernate.org> wrote:

> Hi,
> 
> Working on a demo for OGM, I tried to apply Bean Validation constraints to
> my entities and have them automatically validated during the persistence
> lifecycle.
> 
> This works as expected (which is very nice), the only thing which made me
> wonder is that the resulting ConstraintViolationException is wrapped into a
> RollbackException. Basically that's not surprising as we use TX demarcation
> to control the flush cycle also if the store is actually non-transactional,
> yet it may cause irritations and false expectations by users.
> 
> So I'm wondering whether we rather should raise a more generic
> PersistenceException (or another specialized type which doesn't indicate a
> rollback may happen) when using a non-transactional backend? What do you
> think?
> 
> --Gunnar
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


From paolo.antinori at gmail.com  Wed Apr  2 11:51:54 2014
From: paolo.antinori at gmail.com (Paolo Antinori)
Date: Wed, 2 Apr 2014 16:51:54 +0100
Subject: [hibernate-dev] [OGM] CI jobs hang (Gunnar Morling)
In-Reply-To: <CADGJaX_qBLTBc7qo9GrsQvxKxEqaX_f0_A2mSjUxOK59BV5FfQ@mail.gmail.com>
References: <CAO4Yhkg+2UGP094mzH5NP5a-dN1s_6_PFvoyeymv7-6tMKiQpw@mail.gmail.com>
	<CADGJaX_qBLTBc7qo9GrsQvxKxEqaX_f0_A2mSjUxOK59BV5FfQ@mail.gmail.com>
Message-ID: <CAO4Yhki4vC3eAYhiyXx0YxcNLes-jDEd6LczWc8AC=aXgcdRdg@mail.gmail.com>

Hi Gunnar,

here a small preview of what I am working with at the moment.

Everything is still in beta so technically everything can change in future.

I am working mainly on 2 fronts:

1) allow in-container compilation.
This should help to isolate concurrent build from the network point of
view(no ports clashing) and using iptables from the network altogether(no
risks of spontaneous clusters formation or any related problem). On top of
that switching from one version to another of jdk should be easier since
the complexity of configuring them is hidden inside the containers and no
longer handled an the main host level.

2) Using Docker containers to provide dedicate instances of  external
services
With Docker I can start an instance of Mongo or Couch, that lives in it's
own ip address and that is tied to a specific build job and automatically
disposed at the end of the job. Again, the complexity of the configuration
lives inside the containers, so once that is done the solution is easily
reusable by every devloper, without asking him to manually download and
configure the application.


At jenkins level at the moment I am running invocations similar to this:

IP_DOCKER_HOST=$(ip -f inet -o addr show docker0 | cut -d ' '  -f 7 | cut
-d '/' -f 1) \
PRJ_FOLDER_HOST="$WORKSPACE" \
PRJ_FOLDER_CONTAINER="/data/maven_build_folder" \
MVN_M2_HOST="/home/jenkins/.m2" \
MVN_M2_CONTAINER="/root/.m2" ; \
docker run -v "$PRJ_FOLDER_HOST":"$PRJ_FOLDER_CONTAINER" \
     -v "$MVN_M2_HOST":"$MVN_M2_CONTAINER" \
     -w "$PRJ_FOLDER_CONTAINER" \
      --privileged openjdk7_maven:iptables \
     clean verify  -s $MVN_M2_CONTAINER/settings-search-release.xml
-DskipTests=false -Dcheckstyle.skip=true -DskipDocs=true -DuseDocker=true
-DuseExternalMongoDb -Ddocker.daemon.ip=$IP_DOCKER_HOST


That is a little scary but most ov it is just configuration to share
folders from the host to the container.


See also a couple of screenshots that show how I can have 5 concurrent
running job, building OGM, each one starting its own private disposable
instance of Couch and Mongo.

http://imgur.com/kWZVpLh&gRpts1U#0

http://imgur.com/kWZVpLh&gRpts1U#1


I am right now working on Gradle based build to see if they can also fit
well within this approach.


cheers

paolo


On Tue, Apr 1, 2014 at 2:11 PM, Gunnar Morling <gunnar at hibernate.org> wrote:

> Hi Paolo,
>
> Thanks for your reply. The thing is that these jobs used to work until
> recently, so I'm wondering which change could be causing the problem. Maybe
> a recent update to Jenkins or one of the plug-ins?
>
> Unfortunately we don't have the config audit plug-in anymore which
> provides a history at least of changes to job configs. @Davide, I think I
> had installed it once but I guess it got lost when rebuilding the instance
> via Puppet? Any chance you could add this plug-in permanently?
>
> @Paolo: Would be very interested to learn more about the Docker stuff
> you're working on once you got something :)
>
> --Gunnar
>
>
>
>
>
> 2014-04-01 15:02 GMT+02:00 Paolo Antinori <paolo.antinori at gmail.com>:
>
>> Hi Gunnar
>>
>> I am working on related activities on a replica of ci.hibernate.orgwhere I
>> am playing with Docker and trying to see how well it could fit the the
>> project build needs.
>>
>> When running OGM build job on this replica server, I have noticed the same
>> problem.
>>
>> I think that the problem is related to Axis plugin, like you were pointing
>> out.
>>
>> I have also noticed this:
>>
>> http://ci.hibernate.org/job/hibernate-ogm-master/106/consoleText
>>
>> That is the link for the plain text version of the logs.
>>
>> Not sure if the message you find there:
>>
>> No such file:
>> /var/lib/jenkins/jobs/hibernate-ogm-master/builds/2014-04-01_07-01-01/log
>>
>> Is the blocking problem or just a side-effect of something else.
>>
>> I hope to be able to show soon a Docker based approach to possibly bypass
>> totally this kind of problems.
>>
>> paolo
>>
>>
>> On Tue, Apr 1, 2014 at 12:46 PM, <hibernate-dev-request at lists.jboss.org
>> >wrote:
>>
>> > Send hibernate-dev mailing list submissions to
>> >         hibernate-dev at lists.jboss.org
>> >
>> > To subscribe or unsubscribe via the World Wide Web, visit
>> >         https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> > or, via email, send a message with subject or body 'help' to
>> >         hibernate-dev-request at lists.jboss.org
>> >
>> > You can reach the person managing the list at
>> >         hibernate-dev-owner at lists.jboss.org
>> >
>> > When replying, please edit your Subject line so it is more specific
>> > than "Re: Contents of hibernate-dev digest..."
>> >
>> > Today's Topics:
>> >
>> >    1. [OGM] CI jobs hang (Gunnar Morling)
>> >    2. Re: Session and carrying 3rd party state (Gunnar Morling)
>> >    3. Re: Session and carrying 3rd party state (Gunnar Morling)
>> >
>> >
>> > ---------- Forwarded message ----------
>> > From: Gunnar Morling <gunnar at hibernate.org>
>> > To: "hibernate-dev at lists.jboss.org" <hibernate-dev at lists.jboss.org>
>> > Cc:
>> > Date: Tue, 1 Apr 2014 09:20:28 +0200
>> > Subject: [hibernate-dev] [OGM] CI jobs hang
>> > Hi,
>> >
>> > For some reason, the CI jobs for OGM can't be executed (all jobs,
>> master,
>> > java8, PR seem affected) . They hang forever in an initial state, i.e.
>> > there is no console output and also the sub-jobs are not dispatched
>> (these
>> > are matrix projects). Worse, they can't even be canceled (trying to do
>> so
>> > has no effect), only a server restart helps.
>> >
>> > Have there been any recent changes to the job (or server) config which
>> may
>> > cause this? I found
>> https://issues.jenkins-ci.org/browse/JENKINS-9688which
>> > indicates, that the jobs may be waiting eternally for a resource which
>> they
>> > can't acquire (I don't see any resources requested in the job config,
>> but I
>> > vaguely remember something around JGroups channels).
>> >
>> > Does anyone know what's going on here?
>> >
>> > --Gunnar
>> >
>> >
>> >
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>

From emmanuel at hibernate.org  Wed Apr  2 12:30:18 2014
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Wed, 2 Apr 2014 18:30:18 +0200
Subject: [hibernate-dev] [HSEARCH] Question on TikaBridge
Message-ID: <1849CC63-6D11-4983-8993-C933DF73F98F@hibernate.org>

Hardy,

Today the actual bridge fails during set() if the object passed is not of a specified subset of types (Blob, etc).
This means the failure happens at the first indexing usage.

Is that ok / preferable if I do these type checking at the bridge creation time - in the BridgeProvider. The only thing I cannot handle here is if the user declares the return type as Object and the runtime type happens to be an acceptable type.

It seems like a small flexibility loss and we would gain clearer error messages: if something is annotated @TikaBridge and we don?t support the type we will fail fast.

Can i make that change?

From steve at hibernate.org  Wed Apr  2 13:32:17 2014
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 2 Apr 2014 12:32:17 -0500
Subject: [hibernate-dev] Another @Access quandry
In-Reply-To: <846D64E4-95EA-468E-A887-A3462510EF07@hibernate.org>
References: <CAFdSV9uYWpa44+GPnq37=wh8KaoWfBjeTJOS8mwiGjZi-3Nhbg@mail.gmail.com>
	<CAFm4XO0A353jt2qJGzvTRi_ExV9yUyQoc4R-VZ-hLR80EWWVfQ@mail.gmail.com>
	<20140326130216.GG42990@hibernate.org>
	<CAFdSV9tPdM8F8BseEik_4x9cWa-d1_j-0L1EEnO_-6C4aCOnzw@mail.gmail.com>
	<CAFm4XO2=ckiZau6cYspaYBz6AdXJ+JC8A1E98i6c3yGMGDBWcw@mail.gmail.com>
	<CAFdSV9sAzASQpNjy3yjNkPuyrpBHX7iSuDO5GEhOx+2r57A3cA@mail.gmail.com>
	<CAFdSV9vkjrLFDa=3qghPvNXFqmU4O8fs+asVSRtMHHei=wEd6Q@mail.gmail.com>
	<20140326162159.GK42990@hibernate.org>
	<CAFdSV9vnx9FdFhPp1PMOxAhbEtqOXNp_+oRvX3OFrL6rF+_GLw@mail.gmail.com>
	<6A185A2E-99FA-4BD5-8F35-AAF9CDA6920A@hibernate.org>
	<CAFdSV9s=QuWWDMZZG52MtqR3vZzNrSyBjUFv5JSV5WtgPGH1+A@mail.gmail.com>
	<71CD7D15-68D1-4C50-8998-B861FFB1F885@hibernate.org>
	<CAFm4XO1+otc3Kab_bKzfHqz7i3ATCRhjjYWq7cNHt0Lq41QUSA@mail.gmail.com>
	<CAFdSV9vTdTLjq7hOyz_wtiDVYrwec3sTnuSf8sthKcJNp1vSuA@mail.gmail.com>
	<CAFdSV9v+JLcnhpfnE3H5iVwtTLsKf_jQXb3-H57_GrStpUUt8Q@mail.gmail.com>
	<A1826A46-DF3D-4842-95E9-90B5CE992F79@hibernate.org>
	<CAFdSV9sPHZyJJs2FLB-mGAZCZmk1H4kpGdLfh9i8xOsxLmfMKA@mail.gmail.com>
	<BEB8A497-D4B0-4AC0-AE15-E0ED398DD75D@hibernate.org>
	<CAFdSV9tc6hLP8eaK1N-+LoPLqvh9t9MyBPB9n10DbxbCeR617g@mail.gmail.com>
	<CAFdSV9sC_SwWpyf7=3JUvbbCPnuGZTFPEjOO=BSkwfd3GupmhA@mail.gmail.com>
	<846D64E4-95EA-468E-A887-A3462510EF07@hibernate.org>
Message-ID: <CAFdSV9vvNb8apCMSYjQy=KhEuXQwe+ZkBY9RjNX=in2fmkvHbA@mail.gmail.com>

To wrap up for now... I went ahead an implemented the strategies we
discussed here.  They are represented as:
1) org.hibernate.metamodel.spi.StandardPersistentAttributeMemberResolver
2) org.hibernate.metamodel.spi.LenientPersistentAttributeMemberResolver

StandardPersistentAttributeMemberResolver implements the JPA spec
guidelines as closely as possible.
 LenientPersistentAttributeMemberResolver tries to be more lenient in the
way Sanne mentioned above.  They will be pushed to master shortly if y'all
wanted to take a look.

Yes, MemberDescriptor and JavaTypeDescriptor are the reflite contracts




On Wed, Apr 2, 2014 at 6:34 AM, Hardy Ferentschik <hardy at hibernate.org>wrote:

>
> On 2 Jan 2014, at 04:20, Steve Ebersole <steve at hibernate.org> wrote:
>
> > I have heard no more comments, so I will move forward with this as
> stated earlier.
>
> Sorry for the late reply. I had a read through and what you describe is
> what I would expect (in fact I hope
> I basically implemented it this way on the metamodel branch).
>
> There is a typo in example 4:
>
> @Entity
> @Access(PROPERTY)
> public class PublishedDocument extends Document
>
> Should be @Access(FIELD)
>
>
> > Additionally, I started working the a PoC for the idea of making this
> resolution pluggable.  Here is the initial stroke for the contract:
> >
> >
> > /**
> >  * Contract responsible for resolving the members that identify the
> persistent
> >  * attributes for a given class descriptor representing a managed type.
> >  *
> >  * These members (field or method) would be where we look for mapping
> annotations
> >  * for the attribute.
> >  *
> >  * Additionally, whether the member is a field or method would tell us
> the default
> >  * runtime access strategy
> >  *
> >  * @author Steve Ebersole
> >  */
> > public interface PersistentAttributeMemberResolver {
> >       /**
> >        * Given the ManagedType Java type descriptor and the implicit
> AccessType
> >        * to use, resolve the members that indicate persistent attributes.
> >        *
> >        * @param managedTypeDescriptor The ManagedType Java type
> descriptor
> >        * @param implicitAccessType The implicit AccessType for the
> resolution
> >        *
> >        * @return The list of "backing members"
> >        */
> >       public List<MemberDescriptor> resolveMembers(
> >                       JavaTypeDescriptor managedTypeDescriptor,
> >                       AccessType implicitAccessType);
> > }
>
>
> Where MemberDescriptor and JavaTypeDescriptor are the descriptors from the
> new reflite layer, right?
> This should work.
>
> --Hardy
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From hardy at hibernate.org  Wed Apr  2 14:42:53 2014
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Wed, 2 Apr 2014 20:42:53 +0200
Subject: [hibernate-dev] [HSEARCH] Question on TikaBridge
In-Reply-To: <1849CC63-6D11-4983-8993-C933DF73F98F@hibernate.org>
References: <1849CC63-6D11-4983-8993-C933DF73F98F@hibernate.org>
Message-ID: <5BDEFA8A-EDC5-40EB-A667-11DDC7363CB2@hibernate.org>


On 2 Jan 2014, at 18:30, Emmanuel Bernard <emmanuel at hibernate.org> wrote:

> Hardy,
> 
> Today the actual bridge fails during set() if the object passed is not of a specified subset of types (Blob, etc).

Right, that happens in TikaBridge#getInputStreamForData

> This means the failure happens at the first indexing usage.

Correct

> Is that ok / preferable if I do these type checking at the bridge creation time - in the BridgeProvider.

Not sure. AS you say, the problem is if you define the type as Object. Probably quite uncommon. 

> It seems like a small flexibility loss and we would gain clearer error messages: if something is annotated @TikaBridge and we don?t support the type we will fail fast.

Fail fast sounds good.

?Hardy



From hardy at hibernate.org  Wed Apr  2 15:18:15 2014
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Wed, 2 Apr 2014 21:18:15 +0200
Subject: [hibernate-dev] [HSEARCH] Autodiscoverable field bridges next
	steps
In-Reply-To: <68D0A63C-2D53-4E91-B5B7-33D7845AD1C1@hibernate.org>
References: <4FF34AA8-4475-48ED-91D5-7C5A7528AD70@hibernate.org>
	<D6A3D1B3-1509-4CC8-B630-E3CB4A5FE841@hibernate.org>
	<BDB0B75C-7765-4A26-A042-E33DC2C7E007@hibernate.org>
	<68D0A63C-2D53-4E91-B5B7-33D7845AD1C1@hibernate.org>
Message-ID: <1596B4DF-D4B5-4A1B-9CB9-9CBFBCF6F1EA@hibernate.org>


On 2 Jan 2014, at 17:37, Emmanuel Bernard <emmanuel at hibernate.org> wrote:

> Yes your analysis is correct.

Cool, so we seem to be on the same page then.

> I do think 3 is the most valuable but that 2c is a relatively close second.

+1 for case #3 being the most important one. I would even go so far to say that this is the only one we should address with the BridgeProvider.

> Now the @Spatial and @TikaBridge annotations do have attributes which will influence how the underlying bridge is created.
> I don?t think you are proposing to move the spatial and Tika bridge creation up on AnnotationMetadataProvider.

That?s what I am proposing. Also the processing of the @Bridge annotation (standalone or as part of @Field) should move. Really 
what happens in BridgeFactory#findExplicitFieldBridge (which is funny enough called by something like BridgeFactory#guessType)
is annotation and hence AnnotationMetadataProvider specific. BridgeFactory#guessType could really just become the handler of the described scenario 3.

> That would AFAIU duplicate the bridge creation logic between the AMP and some ProgrammaticMetadataProvider.

No, not really or at most temporarily. Remember, using commons annotations and pseudo annotations are just a crutch. It would be much easier to
instantiate the right metadata and bridges directly. After all the user does explicitly something like .property( "name", ElementType.FIELD ).spatial()
There is not need to guess, you could create the appropriate bridge directly. 

> Also I have a hard time navigating and understanding AnnotationMetadataProvider, so I?m not sure we should make it more complex.

Sure AnnotationMetadataProvider is a lot of code, but it is actually still very similar to the code you originally wrote for DocumentBuilder. It just has moved.
An indexed class is processed by creating the class hierarchy for this class and then iterating the class hierarchy finding indexed properties. You should
be able to follow the  flow quite easily from AnnotationMetadataProvider#initializeClass. Also have a look at the call sites for BridgeFactory#guessType.

> So somehow, the AMP should convert @Spatial, @NumericField, @TikaBridge, and @DateBridge into some non annotation based representation and pass that information to the bridgeFactory.

Somehow you would create the bridge directly. Either from the AnnotationMetadataProvider or we need some additional methods on BridgeFactory.

> Your approach would be to call explicitly buildXxxBridge() - like buildDateBridge() - methods form AMP.

That would be one way of doing it. If these methods would be in BridgeFactory they could even be called from the programmatic config

> These would be hosted on the BridgeFactory. Is that correct?

Right

> And the same explicit call logic would be done on a programmatic API equivalent.

Right

> Now how would you pass and to these kind of explicit calls in the 2c case when the annotation is unknown a priori?

A couple of things here.  buildXxxBridge() are specific to our internal bridges (date, spatial, tika). There is no equivalent for custom (user provided) bridges. They are either 
explicitly configured or go via the BridgeProvider contract. If we truly want to support 2c, we need something like the AnnoatedElement in the contract of BridgeProvider.
On the other hand, 2c can also be solved by the user by specifying his bridge directly. 

If we just think about case #3 BridgeProvider could almost become:

FieldBridge returnFieldBridgeIfMatching(Class<?> returnType, ServiceManager serviceManager);

For me it has many benefits:

1)  It separates completely the annotation processing from the bridge creation, something which is currently in the way for a refactoring of the programmatic config and probably a problem
     for non entity based indexing
2) Probably future proof for non entity based indexing
3) From a development point it treats case #1, #2a and #2b the same way - as explicitly known bridges (which is really the case)
4) There is no major loss in functionality

?Hardy




From hardy at hibernate.org  Wed Apr  2 15:35:35 2014
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Wed, 2 Apr 2014 21:35:35 +0200
Subject: [hibernate-dev] [HSEARCH] [Autodiscoverable] Handling duplicates
In-Reply-To: <4715DF5F-B6AF-4BB2-8457-008F69856CCA@hibernate.org>
References: <4FF34AA8-4475-48ED-91D5-7C5A7528AD70@hibernate.org>
	<D6A3D1B3-1509-4CC8-B630-E3CB4A5FE841@hibernate.org>
	<4715DF5F-B6AF-4BB2-8457-008F69856CCA@hibernate.org>
Message-ID: <3B2362AD-57A1-41C4-BF35-08EEA4C968D7@hibernate.org>


On 2 Jan 2014, at 14:30, Emmanuel Bernard <emmanuel at hibernate.org> wrote:

>>> Sanne questioned the idea of built-in bridge and would rather have all bridges handled equally and not allow duplication.
>>> It seems that the current set of bridges cannot support that approach. When I developed the code, I realised that there is an ordering to respect. If I put the TikeBridgeProvider logic before the date and calendar bridgeProviders, then the DSLTest fails. I could not find why but it shows that we have some interdependencies at the moment.
>> 
>> I think it would be a good idea to fine out what?s going on first.
> 
> So the TikaBridge problem was due to a test placing @TikaBridge on a Date (`@TikaBridge Date someDate`)
> 
> - If @TikaBridge is placed on an unknown type, the bridge fails and the test checks that.
> - if the DateBridgeProvider runs before the TikeBridgeProvider then the exception does not happen as the DataBridgeProvider not only checks for `@DateBridge` but also for naked `Date` return type and wins over tike bridge.

Got you

> ## Option A
> 
> We could force all discoverable bridges to only handle bridges with an explicit annotation e.g. `@MyBridge SomeType`. And handle the non annotated types in the last phase of the BridgeFactory.guessType but a few questions arise:

Or we handle the ones with explicit annotation explicitly and let the BridgeFactory.guessType really just handle the ones we need to ?guess?. Basically what we just discussed in the other thread regarding the BridgeProvider contract

> It offers more flexibility, like the ability to qualify a type with an annotation to discriminate which bridge is expected.

So if you already want to add an annotation to qualify the bridge, why do you not use @Bridge directly?

> I?m fine with starting with option B but latter moving to option C will break backward compatibility. So in the end the question is what do you mean precisely by "Allow loading of additional "built-in bridges" via autodiscovery?.

 "Allow loading of additional "built-in bridges" via auto discovery? - almost sounds like an oxymoron to me. There are built-in bridges and there are discovered bridges. The built-in ones are the ones for the basic data types 
as we define them in BridgeFactory plus the special bridges for spatial, tika, etc

When it comes to bridge auto discovery, I thick we should cover the case

- where a user wants to specify a bridge for a user specific type, so that he can just say @Field for this type
- where the user wants to override one of the basic bridges (String, Integer, ?)

I say basic, since I am not sure whether we should consider overriding of @TikaBridge or @DateBridge. They are somewhat specific Search features. If you want to customise, you could just leave these annotations off altogether 
and provide a BridgeProvider for Lob and Date. Again, no loss in functionality. 

?Hardy

From emmanuel at hibernate.org  Wed Apr  2 17:20:55 2014
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Wed, 2 Apr 2014 23:20:55 +0200
Subject: [hibernate-dev] [HSEARCH] Autodiscoverable field bridges next
	steps
In-Reply-To: <1596B4DF-D4B5-4A1B-9CB9-9CBFBCF6F1EA@hibernate.org>
References: <4FF34AA8-4475-48ED-91D5-7C5A7528AD70@hibernate.org>
	<D6A3D1B3-1509-4CC8-B630-E3CB4A5FE841@hibernate.org>
	<BDB0B75C-7765-4A26-A042-E33DC2C7E007@hibernate.org>
	<68D0A63C-2D53-4E91-B5B7-33D7845AD1C1@hibernate.org>
	<1596B4DF-D4B5-4A1B-9CB9-9CBFBCF6F1EA@hibernate.org>
Message-ID: <40D44986-DB7D-496E-B108-6081E47CB689@hibernate.org>

Please everyone and especially Sanne, read this branch of the exchange Hardy and I have. We need another pair of eyes to make sure we don?t mess things up as it is an important departure compared to how things are done today (and in my prototype).

Hardy, I am starting to come along your side on this discussion. They key things that made me swing is that if a user needs a special annotation to customize the bridge, then it?s equivalent to a @FieldBridge. So a feature like CDI stereotypes or BV?s composition (by annotating a custom annotation with a @FieldBridge) would solve that problem more elegantly.

I am still a bit sceptical to move the bridge discovery to AMP - at least when explicit annotations are at play because:
- AMP is complex
- BridgeFactory seems a nice focal point to everything bridge related
- a few common rules must be applied to bridges (like the IterableBridges / MapBridges and ArrayBridges wrappers)

Nevertheless the idea of inferring types via @FieldBridge, @TikeBridge, @DateBridge, @Spatial in a separate method than guessType has merits.

BUT

In practice for Date related add-ons like JodaTime and Java 8 date, I am wondering if we should ensure that someone can use @DateBridge. After all a resolution is likely conceptually needed and forcing another annotation seems wrong.
Likewise for "Hibernate Spatial? types, it will probably make sense to support them as annotated with @Spatial like we do for Coordinates.

So what do we do about there?

- are they legit use cases (I think they are)
- is that supposed to be supported by some other features unrelated to BridgeProvider?
- should we design BridgeProvider in a way that let them react to these built in annotations? (via explicit methods I suppose).

Emmanuel

PS: I?ve spend around 20hrs on that feature so if we could converge, that would be good :)

On 02 Apr 2014, at 21:18, Hardy Ferentschik <hardy at hibernate.org> wrote:

> 
> On 2 Jan 2014, at 17:37, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
> 
>> Yes your analysis is correct.
> 
> Cool, so we seem to be on the same page then.
> 
>> I do think 3 is the most valuable but that 2c is a relatively close second.
> 
> +1 for case #3 being the most important one. I would even go so far to say that this is the only one we should address with the BridgeProvider.
> 
>> Now the @Spatial and @TikaBridge annotations do have attributes which will influence how the underlying bridge is created.
>> I don?t think you are proposing to move the spatial and Tika bridge creation up on AnnotationMetadataProvider.
> 
> That?s what I am proposing. Also the processing of the @Bridge annotation (standalone or as part of @Field) should move. Really 
> what happens in BridgeFactory#findExplicitFieldBridge (which is funny enough called by something like BridgeFactory#guessType)
> is annotation and hence AnnotationMetadataProvider specific. BridgeFactory#guessType could really just become the handler of the described scenario 3.
> 
>> That would AFAIU duplicate the bridge creation logic between the AMP and some ProgrammaticMetadataProvider.
> 
> No, not really or at most temporarily. Remember, using commons annotations and pseudo annotations are just a crutch. It would be much easier to
> instantiate the right metadata and bridges directly. After all the user does explicitly something like .property( "name", ElementType.FIELD ).spatial()
> There is not need to guess, you could create the appropriate bridge directly. 
> 
>> Also I have a hard time navigating and understanding AnnotationMetadataProvider, so I?m not sure we should make it more complex.
> 
> Sure AnnotationMetadataProvider is a lot of code, but it is actually still very similar to the code you originally wrote for DocumentBuilder. It just has moved.
> An indexed class is processed by creating the class hierarchy for this class and then iterating the class hierarchy finding indexed properties. You should
> be able to follow the  flow quite easily from AnnotationMetadataProvider#initializeClass. Also have a look at the call sites for BridgeFactory#guessType.
> 
>> So somehow, the AMP should convert @Spatial, @NumericField, @TikaBridge, and @DateBridge into some non annotation based representation and pass that information to the bridgeFactory.
> 
> Somehow you would create the bridge directly. Either from the AnnotationMetadataProvider or we need some additional methods on BridgeFactory.
> 
>> Your approach would be to call explicitly buildXxxBridge() - like buildDateBridge() - methods form AMP.
> 
> That would be one way of doing it. If these methods would be in BridgeFactory they could even be called from the programmatic config
> 
>> These would be hosted on the BridgeFactory. Is that correct?
> 
> Right
> 
>> And the same explicit call logic would be done on a programmatic API equivalent.
> 
> Right
> 
>> Now how would you pass and to these kind of explicit calls in the 2c case when the annotation is unknown a priori?
> 
> A couple of things here.  buildXxxBridge() are specific to our internal bridges (date, spatial, tika). There is no equivalent for custom (user provided) bridges. They are either 
> explicitly configured or go via the BridgeProvider contract. If we truly want to support 2c, we need something like the AnnoatedElement in the contract of BridgeProvider.
> On the other hand, 2c can also be solved by the user by specifying his bridge directly. 
> 
> If we just think about case #3 BridgeProvider could almost become:
> 
> FieldBridge returnFieldBridgeIfMatching(Class<?> returnType, ServiceManager serviceManager);
> 
> For me it has many benefits:
> 
> 1)  It separates completely the annotation processing from the bridge creation, something which is currently in the way for a refactoring of the programmatic config and probably a problem
>     for non entity based indexing
> 2) Probably future proof for non entity based indexing
> 3) From a development point it treats case #1, #2a and #2b the same way - as explicitly known bridges (which is really the case)
> 4) There is no major loss in functionality
> 
> ?Hardy
> 
> 



From gunnar at hibernate.org  Wed Apr  2 18:00:56 2014
From: gunnar at hibernate.org (Gunnar Morling)
Date: Thu, 3 Apr 2014 00:00:56 +0200
Subject: [hibernate-dev] [OGM] OGM and Bean Validation
In-Reply-To: <AE122720-E881-4112-85B4-09E1A6A6978D@hibernate.org>
References: <CADGJaX8gQiy6rPii0EvkU-8L28WR97QC+pzgdjLMdHyQCyDQmQ@mail.gmail.com>
	<AE122720-E881-4112-85B4-09E1A6A6978D@hibernate.org>
Message-ID: <CADGJaX8qNC4WfmLswgsR0TH_rn1tqYuMjCA_8Dpr+jRS2Qk+EQ@mail.gmail.com>

Hum, I guess it's one of the cases then where JPA doesn't 100% match for
the purposes of talking to NoSQL.


2014-04-02 17:40 GMT+02:00 Emmanuel Bernard <emmanuel at hibernate.org>:

> This would go against the JPA spec unfortunately.
>
> On 02 Apr 2014, at 16:25, Gunnar Morling <gunnar at hibernate.org> wrote:
>
> > Hi,
> >
> > Working on a demo for OGM, I tried to apply Bean Validation constraints
> to
> > my entities and have them automatically validated during the persistence
> > lifecycle.
> >
> > This works as expected (which is very nice), the only thing which made me
> > wonder is that the resulting ConstraintViolationException is wrapped
> into a
> > RollbackException. Basically that's not surprising as we use TX
> demarcation
> > to control the flush cycle also if the store is actually
> non-transactional,
> > yet it may cause irritations and false expectations by users.
> >
> > So I'm wondering whether we rather should raise a more generic
> > PersistenceException (or another specialized type which doesn't indicate
> a
> > rollback may happen) when using a non-transactional backend? What do you
> > think?
> >
> > --Gunnar
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From emmanuel at hibernate.org  Wed Apr  2 18:06:16 2014
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Thu, 3 Apr 2014 00:06:16 +0200
Subject: [hibernate-dev] [OGM] OGM and Bean Validation
In-Reply-To: <CADGJaX8qNC4WfmLswgsR0TH_rn1tqYuMjCA_8Dpr+jRS2Qk+EQ@mail.gmail.com>
References: <CADGJaX8gQiy6rPii0EvkU-8L28WR97QC+pzgdjLMdHyQCyDQmQ@mail.gmail.com>
	<AE122720-E881-4112-85B4-09E1A6A6978D@hibernate.org>
	<CADGJaX8qNC4WfmLswgsR0TH_rn1tqYuMjCA_8Dpr+jRS2Qk+EQ@mail.gmail.com>
Message-ID: <8F939B23-2DD7-474A-BFF8-09E89BB961C0@hibernate.org>

It?s actually a PITA even in JPA. I wish ConstraintViolationExceptions were not wrapped at all.

On 03 Apr 2014, at 00:00, Gunnar Morling <gunnar at hibernate.org> wrote:

> Hum, I guess it's one of the cases then where JPA doesn't 100% match for the purposes of talking to NoSQL.
> 
> 
> 2014-04-02 17:40 GMT+02:00 Emmanuel Bernard <emmanuel at hibernate.org>:
> This would go against the JPA spec unfortunately.
> 
> On 02 Apr 2014, at 16:25, Gunnar Morling <gunnar at hibernate.org> wrote:
> 
> > Hi,
> >
> > Working on a demo for OGM, I tried to apply Bean Validation constraints to
> > my entities and have them automatically validated during the persistence
> > lifecycle.
> >
> > This works as expected (which is very nice), the only thing which made me
> > wonder is that the resulting ConstraintViolationException is wrapped into a
> > RollbackException. Basically that's not surprising as we use TX demarcation
> > to control the flush cycle also if the store is actually non-transactional,
> > yet it may cause irritations and false expectations by users.
> >
> > So I'm wondering whether we rather should raise a more generic
> > PersistenceException (or another specialized type which doesn't indicate a
> > rollback may happen) when using a non-transactional backend? What do you
> > think?
> >
> > --Gunnar
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> 
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> 


From sanne at hibernate.org  Wed Apr  2 18:57:30 2014
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 2 Apr 2014 23:57:30 +0100
Subject: [hibernate-dev] [HSEARCH] Autodiscoverable field bridges next
	steps
In-Reply-To: <40D44986-DB7D-496E-B108-6081E47CB689@hibernate.org>
References: <4FF34AA8-4475-48ED-91D5-7C5A7528AD70@hibernate.org>
	<D6A3D1B3-1509-4CC8-B630-E3CB4A5FE841@hibernate.org>
	<BDB0B75C-7765-4A26-A042-E33DC2C7E007@hibernate.org>
	<68D0A63C-2D53-4E91-B5B7-33D7845AD1C1@hibernate.org>
	<1596B4DF-D4B5-4A1B-9CB9-9CBFBCF6F1EA@hibernate.org>
	<40D44986-DB7D-496E-B108-6081E47CB689@hibernate.org>
Message-ID: <CAFm4XO2oKAxPg07b46c+t8Bwhz+iyO_jBM9tQFV4UUCHq--pqQ@mail.gmail.com>

On 2 April 2014 22:20, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
> Please everyone and especially Sanne, read this branch of the exchange Hardy and I have. We need another pair of eyes to make sure we don?t mess things up as it is an important departure compared to how things are done today (and in my prototype).

I've been quiet but not ignoring :) Many interesting ideas in this
thread which need settling.

> Hardy, I am starting to come along your side on this discussion. They key things that made me swing is that if a user needs a special annotation to customize the bridge, then it?s equivalent to a @FieldBridge. So a feature like CDI stereotypes or BV?s composition (by annotating a custom annotation with a @FieldBridge) would solve that problem more elegantly.
>
> I am still a bit sceptical to move the bridge discovery to AMP - at least when explicit annotations are at play because:
> - AMP is complex
> - BridgeFactory seems a nice focal point to everything bridge related
> - a few common rules must be applied to bridges (like the IterableBridges / MapBridges and ArrayBridges wrappers)
>
> Nevertheless the idea of inferring types via @FieldBridge, @TikeBridge, @DateBridge, @Spatial in a separate method than guessType has merits.

Yes I agree about the split, and the stereotypes idea is fascinating.
In fact let's highlight that @Tika and @Spatial are fundamentally different:

# @Spatial
  isn't just a bridge, it marks an attribute for very special handling
which goes far beyond the transformation into an indexable
representation, so yes this needs to be treated differently.

# @TikaBridge
  this one is indeed just a "bridge on steroids" with some added sugar
to pass it the parameters in a more explicit way than usafe of
@Parameter

So @Spatial isn't something we can change too much (unless I've missed
a concrete proposal), but the @TikaBridge seems like a nice candidate
to retrofit into a stereotype model. That way, the @TikaBridge
annotation could be packaged in the Tika extension in its separate
module.

In fact, the stereotype subject came up before:
 - http://lists.jboss.org/pipermail/hibernate-dev/2012-May/008335.html

Even beyond this, maybe considering @TikaBridge as an example for this
feature was a terrible mistake I made: the issue at hand is about
providing a default Bridge implementation for well known *types*, but
Tika applies to Blobs and byte arrays! That should really not be a
binding rule without an explicit annotation. Let me amend about that
and just say that implementing extensions like we did with Tika should
be easier for an integrator, so for this one stereotypes really sound
a better path.

>
> BUT
>
> In practice for Date related add-ons like JodaTime and Java 8 date, I am wondering if we should ensure that someone can use @DateBridge. After all a resolution is likely conceptually needed and forcing another annotation seems wrong.

Great point. I agree the same annotation would seem a natural fit for
the other time types.

Usually though we need DateBridge because we need to represent the
desired precision, while in JodaTime (and in Java8) the precision of
the type is represented by specific types. For example
org.joda.time.LocalTime doesn't have the date, it just provides time
of day information (and has no timezone either);
maybe the user doesn't need the milliseconds precision, so that might
be a reason to still need use
org.hibernate.search.annotations.Resolution ?
As otherwise there would be no point in using @DateBridge.

So let's assume that @DateBridge is still needed, and needs to be
compatible with all these; I suspect it could not be retrofitted into
a stereotype annotation, because it would be unclear which extension
module among these time systems should "own" the annotation.
However if we make a specific bridge for each of these types, which
gets automatically in play because of coupling to the type of an
indexed property, and we could consider the @DateBridge annotation as
a DTO for parameters to whatever the actual FieldBridge
implementation?

We could generalize this concept by meta-annotating the @DateBridge
and @CalendarBridge annotations with something like
@ParameterToFieldBridge : any user annotation on a field with such an
annotation, is passed to the registered FieldBridge for that type.

A nice additional consequence would be to retrofit @NumericField into
the same model: its primary purpose is to carry the precision and
format options to the backing bridge implementation.

To resume the attack to the Tika problem: the @TikaBridge annotation
could be both binding the bridge implementation to the property, and
be the @ParameterToFieldBridge to hold parameters to the bridge
implementation.


> Likewise for "Hibernate Spatial? types, it will probably make sense to support them as annotated with @Spatial like we do for Coordinates.

Yes we could do that, as long as the indexed type represents a Point
and not a complex shape. But Spatial is a special case anyway and I
don't think we can generalize here to retrofit it into a stereotype
model.

> So what do we do about there?
>
> - are they legit use cases (I think they are)

+1

> - is that supposed to be supported by some other features unrelated to BridgeProvider?

I lost the subject :)

> - should we design BridgeProvider in a way that let them react to these built in annotations? (via explicit methods I suppose).

Spatial is special, so probably needs explicit handling. All others
might be handled with a combination of @ParameterToFieldBridge (or
whatever better name you all will agree on) and a BridgeProvider
accepting the respective type. Conceptually this means you'd be able
to provide a custom function (code) and a way to get any parameters
passed to it: no limit to creativity :)

Unrelated to the discussion, but to fuel the brainstorming on nice use
cases: custom Hibernate types, Money, @ElementCollection. Probably
even an Embeddable Component could be indexed via a bridge coupled to
its type as an alternative strategy to @IndexedEmbedded.

Sanne

>
> Emmanuel
>
> PS: I?ve spend around 20hrs on that feature so if we could converge, that would be good :)
>
> On 02 Apr 2014, at 21:18, Hardy Ferentschik <hardy at hibernate.org> wrote:
>
>>
>> On 2 Jan 2014, at 17:37, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
>>
>>> Yes your analysis is correct.
>>
>> Cool, so we seem to be on the same page then.
>>
>>> I do think 3 is the most valuable but that 2c is a relatively close second.
>>
>> +1 for case #3 being the most important one. I would even go so far to say that this is the only one we should address with the BridgeProvider.
>>
>>> Now the @Spatial and @TikaBridge annotations do have attributes which will influence how the underlying bridge is created.
>>> I don?t think you are proposing to move the spatial and Tika bridge creation up on AnnotationMetadataProvider.
>>
>> That?s what I am proposing. Also the processing of the @Bridge annotation (standalone or as part of @Field) should move. Really
>> what happens in BridgeFactory#findExplicitFieldBridge (which is funny enough called by something like BridgeFactory#guessType)
>> is annotation and hence AnnotationMetadataProvider specific. BridgeFactory#guessType could really just become the handler of the described scenario 3.
>>
>>> That would AFAIU duplicate the bridge creation logic between the AMP and some ProgrammaticMetadataProvider.
>>
>> No, not really or at most temporarily. Remember, using commons annotations and pseudo annotations are just a crutch. It would be much easier to
>> instantiate the right metadata and bridges directly. After all the user does explicitly something like .property( "name", ElementType.FIELD ).spatial()
>> There is not need to guess, you could create the appropriate bridge directly.
>>
>>> Also I have a hard time navigating and understanding AnnotationMetadataProvider, so I?m not sure we should make it more complex.
>>
>> Sure AnnotationMetadataProvider is a lot of code, but it is actually still very similar to the code you originally wrote for DocumentBuilder. It just has moved.
>> An indexed class is processed by creating the class hierarchy for this class and then iterating the class hierarchy finding indexed properties. You should
>> be able to follow the  flow quite easily from AnnotationMetadataProvider#initializeClass. Also have a look at the call sites for BridgeFactory#guessType.
>>
>>> So somehow, the AMP should convert @Spatial, @NumericField, @TikaBridge, and @DateBridge into some non annotation based representation and pass that information to the bridgeFactory.
>>
>> Somehow you would create the bridge directly. Either from the AnnotationMetadataProvider or we need some additional methods on BridgeFactory.
>>
>>> Your approach would be to call explicitly buildXxxBridge() - like buildDateBridge() - methods form AMP.
>>
>> That would be one way of doing it. If these methods would be in BridgeFactory they could even be called from the programmatic config
>>
>>> These would be hosted on the BridgeFactory. Is that correct?
>>
>> Right
>>
>>> And the same explicit call logic would be done on a programmatic API equivalent.
>>
>> Right
>>
>>> Now how would you pass and to these kind of explicit calls in the 2c case when the annotation is unknown a priori?
>>
>> A couple of things here.  buildXxxBridge() are specific to our internal bridges (date, spatial, tika). There is no equivalent for custom (user provided) bridges. They are either
>> explicitly configured or go via the BridgeProvider contract. If we truly want to support 2c, we need something like the AnnoatedElement in the contract of BridgeProvider.
>> On the other hand, 2c can also be solved by the user by specifying his bridge directly.
>>
>> If we just think about case #3 BridgeProvider could almost become:
>>
>> FieldBridge returnFieldBridgeIfMatching(Class<?> returnType, ServiceManager serviceManager);
>>
>> For me it has many benefits:
>>
>> 1)  It separates completely the annotation processing from the bridge creation, something which is currently in the way for a refactoring of the programmatic config and probably a problem
>>     for non entity based indexing
>> 2) Probably future proof for non entity based indexing
>> 3) From a development point it treats case #1, #2a and #2b the same way - as explicitly known bridges (which is really the case)
>> 4) There is no major loss in functionality
>>
>> ?Hardy
>>
>>
>
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


From sanne at hibernate.org  Wed Apr  2 19:27:08 2014
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 3 Apr 2014 00:27:08 +0100
Subject: [hibernate-dev] [HSEARCH] Question on TikaBridge
In-Reply-To: <5BDEFA8A-EDC5-40EB-A667-11DDC7363CB2@hibernate.org>
References: <1849CC63-6D11-4983-8993-C933DF73F98F@hibernate.org>
	<5BDEFA8A-EDC5-40EB-A667-11DDC7363CB2@hibernate.org>
Message-ID: <CAFm4XO3AywLKBCS-ZgV0WywQXjR1Jk=SdPP8J8n4-PT8aPys=Q@mail.gmail.com>

On 2 April 2014 19:42, Hardy Ferentschik <hardy at hibernate.org> wrote:
>
> On 2 Jan 2014, at 18:30, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
>
>> Hardy,
>>
>> Today the actual bridge fails during set() if the object passed is not of a specified subset of types (Blob, etc).
>
> Right, that happens in TikaBridge#getInputStreamForData
>
>> This means the failure happens at the first indexing usage.
>
> Correct
>
>> Is that ok / preferable if I do these type checking at the bridge creation time - in the BridgeProvider.
>
> Not sure. AS you say, the problem is if you define the type as Object. Probably quite uncommon.

I'd enforce it. If a getter guarantees to provide a refined type, it
could as well make it explicit on the signature.
There is no (sane) reason to refuse fixing the signature, if you know
for sure what you're returning will be compatible. Worst case the
implementor will need to explicitly downcast, but when the CCE strikes
he'll easily see his mistake.

>> It seems like a small flexibility loss and we would gain clearer error messages: if something is annotated @TikaBridge and we don?t support the type we will fail fast.
>
> Fail fast sounds good.

+1

>
> ?Hardy
>
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


From emmanuel at hibernate.org  Thu Apr  3 02:52:37 2014
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Thu, 3 Apr 2014 08:52:37 +0200
Subject: [hibernate-dev] [HSEARCH] Question on TikaBridge
In-Reply-To: <CAFm4XO3AywLKBCS-ZgV0WywQXjR1Jk=SdPP8J8n4-PT8aPys=Q@mail.gmail.com>
References: <1849CC63-6D11-4983-8993-C933DF73F98F@hibernate.org>
	<5BDEFA8A-EDC5-40EB-A667-11DDC7363CB2@hibernate.org>
	<CAFm4XO3AywLKBCS-ZgV0WywQXjR1Jk=SdPP8J8n4-PT8aPys=Q@mail.gmail.com>
Message-ID: <70101A34-8B04-4959-9BD0-D0AB112FE06B@hibernate.org>


>>> Is that ok / preferable if I do these type checking at the bridge creation time - in the BridgeProvider.
>> 
>> Not sure. AS you say, the problem is if you define the type as Object. Probably quite uncommon.
> 
> I'd enforce it. If a getter guarantees to provide a refined type, it
> could as well make it explicit on the signature.
> There is no (sane) reason to refuse fixing the signature, if you know
> for sure what you're returning will be compatible. Worst case the
> implementor will need to explicitly downcast, but when the CCE strikes
> he'll easily see his mistake.
> 

Well my point was that a method returning Blob|String (in Ceylon speak) would always be valid. The only way to represent that in Java is to return Object. But that's probably a rare use case. 

From hardy at hibernate.org  Thu Apr  3 04:44:33 2014
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Thu, 3 Apr 2014 10:44:33 +0200
Subject: [hibernate-dev] [HSEARCH] Autodiscoverable field bridges next
	steps
In-Reply-To: <40D44986-DB7D-496E-B108-6081E47CB689@hibernate.org>
References: <4FF34AA8-4475-48ED-91D5-7C5A7528AD70@hibernate.org>
	<D6A3D1B3-1509-4CC8-B630-E3CB4A5FE841@hibernate.org>
	<BDB0B75C-7765-4A26-A042-E33DC2C7E007@hibernate.org>
	<68D0A63C-2D53-4E91-B5B7-33D7845AD1C1@hibernate.org>
	<1596B4DF-D4B5-4A1B-9CB9-9CBFBCF6F1EA@hibernate.org>
	<40D44986-DB7D-496E-B108-6081E47CB689@hibernate.org>
Message-ID: <411307A5-C455-42AB-8982-7A6F34414DAB@hibernate.org>


On 2 Jan 2014, at 23:20, Emmanuel Bernard <emmanuel at hibernate.org> wrote:

> Hardy, I am starting to come along your side on this discussion. They key things that made me swing is that if a user needs a special annotation to customize the bridge, then it?s equivalent to a @FieldBridge.

Exactly. And parameters you get in via @Parameter if you wan to 

> I am still a bit sceptical to move the bridge discovery to AMP - at least when explicit annotations are at play because:
> - AMP is complex

It is still very complex for sure. I would love to spend more time on this. Basically it is just an extraction of the annotation processing from the DocumentBuilder with the difference that is uses 
now the builder pattern. The basic flow is the same though. Complex or not, processing of the annotation belong there, either directly or in another helper called from there. If you feel for it
you can try to break up the whole class ;-)

> - BridgeFactory seems a nice focal point to everything bridge related

Right, all bridge related. That does imo not include dealing with annotations. We we said, o the BridgeFactory we could have things like buildSpatialBridge(?) which takes everything it needs 
to build such a bridge. However, the extraction of these parameter should happen as part of AnnotationMetadataProvider.

> - a few common rules must be applied to bridges (like the IterableBridges / MapBridges and ArrayBridges wrappers)

Maybe. I dig not deep enough to see all the required detail, but it should be solvable.

> Nevertheless the idea of inferring types via @FieldBridge, @TikeBridge, @DateBridge, @Spatial in a separate method than guessType has merits.

thanks

> BUT
> 
> In practice for Date related add-ons like JodaTime and Java 8 date, I am wondering if we should ensure that someone can use @DateBridge. After all a resolution is likely conceptually needed and forcing another annotation seems wrong.

This one is a border case. I could either handle this case specifically (not using the BridgeProvider) or we live with this shortcoming. It seems like a small flexibility loss and we would gain clearer design and API ;-)

> Likewise for "Hibernate Spatial? types, it will probably make sense to support them as annotated with @Spatial like we do for Coordinates.

I have a hard time that anyone wants to literally override the brig for @Spatial. Once you want to customise there, you might as well not use @Spatial and do your own stuff. Same for @TikaBridge. To a certain degree they are
just shorthands for @FieldBridge(impl=SpatialFoo.class).  

> - is that supposed to be supported by some other features unrelated to BridgeProvider?

Maybe. One idea could be to add a bridgeImpl attribute to @Spatial and @TikaBridge. But as said, see these two annotations more as already selecting one specific bridge type

> - should we design BridgeProvider in a way that let them react to these built in annotations? (via explicit methods I suppose).

Not for me. At least not for the first cut.

?Hardy



From hardy at hibernate.org  Thu Apr  3 08:24:10 2014
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Thu, 3 Apr 2014 14:24:10 +0200
Subject: [hibernate-dev] [Search] Regression with @ContainedIn between
	4.3 and 4.4
In-Reply-To: <CALt0+o-mqa4+DBzajsPchhKPL8qmZashiE7GACrOXzyqV=YoOw@mail.gmail.com>
References: <CALt0+o9=3c9dNiCrR22xhz_nF0Pr2hOiB7foRNsmLbN6dVGv3A@mail.gmail.com>
	<CALt0+o_PDgDZCXYTF3YWekkpq2B4JjJUJ_MNdHaZWC1Q8AngBw@mail.gmail.com>
	<89310918-F608-473D-A0DF-08A2736F68F7@hibernate.org>
	<CALt0+o-CmkLz_5pWCWtaP_DxJE6_xNa5qrxztVyucLa0U7DK_Q@mail.gmail.com>
	<CALt0+o8LeEYhQRQ+i9uPVRCUp9K2_6DjcBvNRAsg3mq3sjQvZw@mail.gmail.com>
	<0F09FD86-F2EB-4336-A267-070A9FA388A2@hibernate.org>
	<20140328111619.GA61492@hibernate.org>
	<5EDB4368-A648-4CC3-A64E-6F809632D817@hibernate.org>
	<CAFm4XO209f-2T=5qnZKv4fLYNcUzUCgd3h2QsPOP7+OVmDB-bA@mail.gmail.com>
	<CALt0+o952kn_naszUWpnSw1XYxFP9DFBErBbf5CzHWza=LDcHA@mail.gmail.com>
	<CALt0+o-mqa4+DBzajsPchhKPL8qmZashiE7GACrOXzyqV=YoOw@mail.gmail.com>
Message-ID: <DC82E66F-9734-454D-8428-1B7D4EAB2C02@hibernate.org>

Hi,

I think we dropped the ball on this one. I basically had a look at Guillaume?s pull request.
His analysis was correct and his proposed patch brings back the old pre 4.4 behaviour
with minimal changes.

There is still the question of the indented use cases of @ContainedIn. As discussed in this thread
afaik the indent was as a sole counterpart to @IndexedEmbedded. The implementation (probably
as a side effect) made it also work when @IndexedEmbedded was not used. This was changed with
the metamodel refactoring where contained in was indeed treated as counterpart of indexed embedded. 

I think we should go ahead and apply Guillaume?s pull request for 4.4 and 4.5, basically reinstating
old 4.x behaviour, side effect or not.

The next question is then what to do in Search 5. I think we can just carry forward the change/patch.
I don?t think that @ContainedIn needs another attribute or that we should introduce a whole new annotation.
@ContainedIn seems quite natural provided we documented it intend and behaviour. Basically all what @ContainedIn
is saying, is that here we have a reference to another entity which needs reindexing as well when the current
entity gets reindexed. Whether the inclusions happens via @IndexEmbedded or via a custom bridge is irrelevant. 

Thoughts?

?Hardy

P.S. Sanne, are you planning 4.4 and 4.5 releases as well? Just asking due to the recent back ports. If so, we should
include this patch as well.





On 28 Jan 2014, at 14:32, Guillaume Smet <guillaume.smet at gmail.com> wrote:

> Hi again,
> 
> I posted a pull request for the 4.5 branch:
> https://github.com/hibernate/hibernate-search/pull/590 . Comments
> welcome!
> 
> I included a rather large test case I have extracted from our app.
> It's simplified but I think you should get the idea by looking at it.
> 
> All tests passes.
> 
> FWIW, I find the new way to do it more consistent with the names of
> the methods as updateContainedInMaxDepths now does exactly what its
> name says.
> 
> It would be nice if it could also be backported to 4.4.x.
> 
> Glad to discuss further enhancements if needed but I think the old
> behavior should be brought back before considering any further
> enhancements/features.
> 
> -- 
> Guillaume
> 
> On Fri, Mar 28, 2014 at 1:28 PM, Guillaume Smet
> <guillaume.smet at gmail.com> wrote:
>> Hi Sanne,
>> 
>> On Fri, Mar 28, 2014 at 12:56 PM, Sanne Grinovero <sanne at hibernate.org> wrote:
>>> However - I might not have fully grasped this yet - but I'm thinking
>>> that this is a feature request and not a bugfix that should be hastily
>>> applied on 4.4.
>> 
>> It's not a feature request. 4.4 changed this behavior. It was working
>> well with 4.3 (and every other versions before that).
>> 
>>> Guillaume, I suspect you might be a happier user if you would keep
>>> using a more bleeding edge version, so to catch any such thing earlier
>>> rather than the day before you go in production. I can only promise
>>> you that the migration to 5.0 will be a nightmare if you don't follow
>>> along in small iterations :-(
>> 
>> I don't think we can be more bleeding edge than us. We upgrade our
>> core framework to new versions as soon as they are released (we coded
>> https://www.artifact-listener.org/ for this purpose). That's why we
>> spend a considerable amount of time doing QA on the components we use
>> - you see a part of this work on ORM + Search but we also do it for
>> other components. You might have noticed that we are often the first
>> company out there to catch regressions.
>> 
>> When we have the ability to dedicate cycles to it, we also test CR.
>> 
>> But... we develop a lot of applications for a lot of customers and
>> they have different lifecycles: we can upgrade some easily and for
>> others we have to wait for the right opportunity to do it.
>> 
>> All in all, we have the following policy:
>> - all the applications in development: they use the latest versions of
>> each components, except if we catch a regression when upgrading. If so
>> we try to help fix it for the next version and we upgrade ASAP;
>> - the applications in production are updated regularly for minor
>> changes; If the changes are big, we wait for our customers to ask
>> changes on the app and we do it then.
>> 
>> The fact is that we caught this one while upgrading an app which was
>> using 4.3.0.Final (which is not that old) but I think we have other
>> applications already upgraded to 4.4.2 which have that bug, it's just
>> that we haven't caught it when we upgraded.
>> 
>> FWIW, we couldn't upgrade to 4.4.x before 4.4.2.Final because of a few
>> regressions we reported and helped getting fixed (I have at least
>> these ones in mind: HSEARCH-1442 and HSEARCH-1462 but IIRC we had
>> others).
>> 
>> (Sorry for the noise but I thought it was a good opportunity to
>> explain how we work, considering we're involved in this community for
>> quite a long time now)
>> 
>> --
>> Guillaume
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev



From sanne at hibernate.org  Thu Apr  3 09:28:57 2014
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 3 Apr 2014 14:28:57 +0100
Subject: [hibernate-dev] [Search] Regression with @ContainedIn between
 4.3 and 4.4
In-Reply-To: <DC82E66F-9734-454D-8428-1B7D4EAB2C02@hibernate.org>
References: <CALt0+o9=3c9dNiCrR22xhz_nF0Pr2hOiB7foRNsmLbN6dVGv3A@mail.gmail.com>
	<CALt0+o_PDgDZCXYTF3YWekkpq2B4JjJUJ_MNdHaZWC1Q8AngBw@mail.gmail.com>
	<89310918-F608-473D-A0DF-08A2736F68F7@hibernate.org>
	<CALt0+o-CmkLz_5pWCWtaP_DxJE6_xNa5qrxztVyucLa0U7DK_Q@mail.gmail.com>
	<CALt0+o8LeEYhQRQ+i9uPVRCUp9K2_6DjcBvNRAsg3mq3sjQvZw@mail.gmail.com>
	<0F09FD86-F2EB-4336-A267-070A9FA388A2@hibernate.org>
	<20140328111619.GA61492@hibernate.org>
	<5EDB4368-A648-4CC3-A64E-6F809632D817@hibernate.org>
	<CAFm4XO209f-2T=5qnZKv4fLYNcUzUCgd3h2QsPOP7+OVmDB-bA@mail.gmail.com>
	<CALt0+o952kn_naszUWpnSw1XYxFP9DFBErBbf5CzHWza=LDcHA@mail.gmail.com>
	<CALt0+o-mqa4+DBzajsPchhKPL8qmZashiE7GACrOXzyqV=YoOw@mail.gmail.com>
	<DC82E66F-9734-454D-8428-1B7D4EAB2C02@hibernate.org>
Message-ID: <CAFm4XO1RwRERoKE08C57=RLX5SV9p3oM3wktjBFmMB3LmL+Myw@mail.gmail.com>

On 3 April 2014 13:24, Hardy Ferentschik <hardy at hibernate.org> wrote:
> Hi,
>
> I think we dropped the ball on this one. I basically had a look at Guillaume?s pull request.
> His analysis was correct and his proposed patch brings back the old pre 4.4 behaviour
> with minimal changes.

Ok that sounds good, I couldn't look at the PR yet.. should I not trust you ? :)

>
> There is still the question of the indented use cases of @ContainedIn. As discussed in this thread
> afaik the indent was as a sole counterpart to @IndexedEmbedded. The implementation (probably
> as a side effect) made it also work when @IndexedEmbedded was not used. This was changed with
> the metamodel refactoring where contained in was indeed treated as counterpart of indexed embedded.
>
> I think we should go ahead and apply Guillaume?s pull request for 4.4 and 4.5, basically reinstating
> old 4.x behaviour, side effect or not.

+1

>
> The next question is then what to do in Search 5. I think we can just carry forward the change/patch.

Yes let's keep them in sync for now

> I don?t think that @ContainedIn needs another attribute or that we should introduce a whole new annotation.
> @ContainedIn seems quite natural provided we documented it intend and behaviour. Basically all what @ContainedIn
> is saying, is that here we have a reference to another entity which needs reindexing as well when the current
> entity gets reindexed. Whether the inclusions happens via @IndexEmbedded or via a custom bridge is irrelevant.
>
> Thoughts?

I agree with you, but in insight if this new "meaning" would have been
explicit on this annotation from the beginning of time, maybe it would
have had a different name?
I don't think the name is appropriate for this more extended meaning;
probably not a big problem but we can decide on that after it's fixed.

> ?Hardy
>
> P.S. Sanne, are you planning 4.4 and 4.5 releases as well? Just asking due to the recent back ports. If so, we should
> include this patch as well.

Some of the backports I did because I indeed want to maintain these
older branches, although to keep them stable I'd not be too eager on
backports.
We don't have dates defined, but we can certainly release these when
there are enough good reasons to: for example if Guillaume needs it.

Sanne

>
>
>
>
>
> On 28 Jan 2014, at 14:32, Guillaume Smet <guillaume.smet at gmail.com> wrote:
>
>> Hi again,
>>
>> I posted a pull request for the 4.5 branch:
>> https://github.com/hibernate/hibernate-search/pull/590 . Comments
>> welcome!
>>
>> I included a rather large test case I have extracted from our app.
>> It's simplified but I think you should get the idea by looking at it.
>>
>> All tests passes.
>>
>> FWIW, I find the new way to do it more consistent with the names of
>> the methods as updateContainedInMaxDepths now does exactly what its
>> name says.
>>
>> It would be nice if it could also be backported to 4.4.x.
>>
>> Glad to discuss further enhancements if needed but I think the old
>> behavior should be brought back before considering any further
>> enhancements/features.
>>
>> --
>> Guillaume
>>
>> On Fri, Mar 28, 2014 at 1:28 PM, Guillaume Smet
>> <guillaume.smet at gmail.com> wrote:
>>> Hi Sanne,
>>>
>>> On Fri, Mar 28, 2014 at 12:56 PM, Sanne Grinovero <sanne at hibernate.org> wrote:
>>>> However - I might not have fully grasped this yet - but I'm thinking
>>>> that this is a feature request and not a bugfix that should be hastily
>>>> applied on 4.4.
>>>
>>> It's not a feature request. 4.4 changed this behavior. It was working
>>> well with 4.3 (and every other versions before that).
>>>
>>>> Guillaume, I suspect you might be a happier user if you would keep
>>>> using a more bleeding edge version, so to catch any such thing earlier
>>>> rather than the day before you go in production. I can only promise
>>>> you that the migration to 5.0 will be a nightmare if you don't follow
>>>> along in small iterations :-(
>>>
>>> I don't think we can be more bleeding edge than us. We upgrade our
>>> core framework to new versions as soon as they are released (we coded
>>> https://www.artifact-listener.org/ for this purpose). That's why we
>>> spend a considerable amount of time doing QA on the components we use
>>> - you see a part of this work on ORM + Search but we also do it for
>>> other components. You might have noticed that we are often the first
>>> company out there to catch regressions.
>>>
>>> When we have the ability to dedicate cycles to it, we also test CR.
>>>
>>> But... we develop a lot of applications for a lot of customers and
>>> they have different lifecycles: we can upgrade some easily and for
>>> others we have to wait for the right opportunity to do it.
>>>
>>> All in all, we have the following policy:
>>> - all the applications in development: they use the latest versions of
>>> each components, except if we catch a regression when upgrading. If so
>>> we try to help fix it for the next version and we upgrade ASAP;
>>> - the applications in production are updated regularly for minor
>>> changes; If the changes are big, we wait for our customers to ask
>>> changes on the app and we do it then.
>>>
>>> The fact is that we caught this one while upgrading an app which was
>>> using 4.3.0.Final (which is not that old) but I think we have other
>>> applications already upgraded to 4.4.2 which have that bug, it's just
>>> that we haven't caught it when we upgraded.
>>>
>>> FWIW, we couldn't upgrade to 4.4.x before 4.4.2.Final because of a few
>>> regressions we reported and helped getting fixed (I have at least
>>> these ones in mind: HSEARCH-1442 and HSEARCH-1462 but IIRC we had
>>> others).
>>>
>>> (Sorry for the noise but I thought it was a good opportunity to
>>> explain how we work, considering we're involved in this community for
>>> quite a long time now)
>>>
>>> --
>>> Guillaume
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>


From guillaume.smet at gmail.com  Thu Apr  3 10:07:53 2014
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Thu, 3 Apr 2014 16:07:53 +0200
Subject: [hibernate-dev] [Search] Regression with @ContainedIn between
 4.3 and 4.4
In-Reply-To: <CAFm4XO1RwRERoKE08C57=RLX5SV9p3oM3wktjBFmMB3LmL+Myw@mail.gmail.com>
References: <CALt0+o9=3c9dNiCrR22xhz_nF0Pr2hOiB7foRNsmLbN6dVGv3A@mail.gmail.com>
	<CALt0+o_PDgDZCXYTF3YWekkpq2B4JjJUJ_MNdHaZWC1Q8AngBw@mail.gmail.com>
	<89310918-F608-473D-A0DF-08A2736F68F7@hibernate.org>
	<CALt0+o-CmkLz_5pWCWtaP_DxJE6_xNa5qrxztVyucLa0U7DK_Q@mail.gmail.com>
	<CALt0+o8LeEYhQRQ+i9uPVRCUp9K2_6DjcBvNRAsg3mq3sjQvZw@mail.gmail.com>
	<0F09FD86-F2EB-4336-A267-070A9FA388A2@hibernate.org>
	<20140328111619.GA61492@hibernate.org>
	<5EDB4368-A648-4CC3-A64E-6F809632D817@hibernate.org>
	<CAFm4XO209f-2T=5qnZKv4fLYNcUzUCgd3h2QsPOP7+OVmDB-bA@mail.gmail.com>
	<CALt0+o952kn_naszUWpnSw1XYxFP9DFBErBbf5CzHWza=LDcHA@mail.gmail.com>
	<CALt0+o-mqa4+DBzajsPchhKPL8qmZashiE7GACrOXzyqV=YoOw@mail.gmail.com>
	<DC82E66F-9734-454D-8428-1B7D4EAB2C02@hibernate.org>
	<CAFm4XO1RwRERoKE08C57=RLX5SV9p3oM3wktjBFmMB3LmL+Myw@mail.gmail.com>
Message-ID: <CALt0+o_EbcKJyeyqCbTTpBzL3ZTF6Bs02rkRcLdhZgpM2kEBqw@mail.gmail.com>

Hi Sanne,

On Thu, Apr 3, 2014 at 3:28 PM, Sanne Grinovero <sanne at hibernate.org> wrote:
> We don't have dates defined, but we can certainly release these when
> there are enough good reasons to: for example if Guillaume needs it.

It would be nice to have an official release once we have a fix for
https://hibernate.atlassian.net/browse/HSEARCH-1583 but I don't think
it's a good idea to release something before that as it's a kinda
annoying one too.

We have moved our most advanced/tested application in terms of
indexing features to 4.4 so I think we probably won't find any more
regression in it as for the features we use (we can't move this app to
ORM 4.3 for now due to other big changes in our core framework).

We have a couple of applications running on ORM 4.3 + Search 4.5 and
we don't have any problem apart from the ones we already opened.

-- 
Guillaume

From hardy at hibernate.org  Thu Apr  3 14:18:45 2014
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Thu, 3 Apr 2014 20:18:45 +0200
Subject: [hibernate-dev] [Search] Regression with @ContainedIn between
	4.3 and 4.4
In-Reply-To: <CAFm4XO1RwRERoKE08C57=RLX5SV9p3oM3wktjBFmMB3LmL+Myw@mail.gmail.com>
References: <CALt0+o9=3c9dNiCrR22xhz_nF0Pr2hOiB7foRNsmLbN6dVGv3A@mail.gmail.com>
	<CALt0+o_PDgDZCXYTF3YWekkpq2B4JjJUJ_MNdHaZWC1Q8AngBw@mail.gmail.com>
	<89310918-F608-473D-A0DF-08A2736F68F7@hibernate.org>
	<CALt0+o-CmkLz_5pWCWtaP_DxJE6_xNa5qrxztVyucLa0U7DK_Q@mail.gmail.com>
	<CALt0+o8LeEYhQRQ+i9uPVRCUp9K2_6DjcBvNRAsg3mq3sjQvZw@mail.gmail.com>
	<0F09FD86-F2EB-4336-A267-070A9FA388A2@hibernate.org>
	<20140328111619.GA61492@hibernate.org>
	<5EDB4368-A648-4CC3-A64E-6F809632D817@hibernate.org>
	<CAFm4XO209f-2T=5qnZKv4fLYNcUzUCgd3h2QsPOP7+OVmDB-bA@mail.gmail.com>
	<CALt0+o952kn_naszUWpnSw1XYxFP9DFBErBbf5CzHWza=LDcHA@mail.gmail.com>
	<CALt0+o-mqa4+DBzajsPchhKPL8qmZashiE7GACrOXzyqV=YoOw@mail.gmail.com>
	<DC82E66F-9734-454D-8428-1B7D4EAB2C02@hibernate.org>
	<CAFm4XO1RwRERoKE08C57=RLX5SV9p3oM3wktjBFmMB3LmL+Myw@mail.gmail.com>
Message-ID: <388F744A-5955-40E1-B878-C52635064C64@hibernate.org>


On 3 Jan 2014, at 15:28, Sanne Grinovero <sanne at hibernate.org> wrote:

>> I think we dropped the ball on this one. I basically had a look at Guillaume?s pull request.
>> His analysis was correct and his proposed patch brings back the old pre 4.4 behaviour
>> with minimal changes.
> 
> Ok that sounds good, I couldn't look at the PR yet.. should I not trust you ? :)

You definitely, should ;-) I just felt that we kind of left the discussion open ended.

>> There is still the question of the indented use cases of @ContainedIn. As discussed in this thread
>> afaik the indent was as a sole counterpart to @IndexedEmbedded. The implementation (probably
>> as a side effect) made it also work when @IndexedEmbedded was not used. This was changed with
>> the metamodel refactoring where contained in was indeed treated as counterpart of indexed embedded.
>> 
>> I think we should go ahead and apply Guillaume?s pull request for 4.4 and 4.5, basically reinstating
>> old 4.x behaviour, side effect or not.
> 
> +1

Ok then

>> The next question is then what to do in Search 5. I think we can just carry forward the change/patch.
> 
> Yes let's keep them in sync for now
> 
>> I don?t think that @ContainedIn needs another attribute or that we should introduce a whole new annotation.
>> @ContainedIn seems quite natural provided we documented it intend and behaviour. Basically all what @ContainedIn
>> is saying, is that here we have a reference to another entity which needs reindexing as well when the current
>> entity gets reindexed. Whether the inclusions happens via @IndexEmbedded or via a custom bridge is irrelevant.
>> 
>> Thoughts?
> 
> I agree with you, but in insight if this new "meaning" would have been
> explicit on this annotation from the beginning of time, maybe it would
> have had a different name?

Maybe. But what? @ContainedIn kind of fits.

> I don't think the name is appropriate for this more extended meaning;
> probably not a big problem but we can decide on that after it's fixed.

Sure.

> We don't have dates defined, but we can certainly release these when
> there are enough good reasons to: for example if Guillaume needs it.

ok

From steve at hibernate.org  Thu Apr  3 20:48:24 2014
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 3 Apr 2014 19:48:24 -0500
Subject: [hibernate-dev] CI environment
Message-ID: <CAFdSV9t5jS24y7CQV3B5ubOgHByu-1Tvs=8yoA_oUfC7SnR31Q@mail.gmail.com>

There is something very very funky going on in the CI environment.

The ORM master job hangs almost every run now.  Oddly, it hangs trying to
compile test classes. I have tried a number of things in attempt to find
out why.  I have added `strace` to the job command, ssh'iong to the box and
manually watching processes.  None of this has illuminated the cause for
me.  Interestingly, I tried using Gradle's --debug option but then of
course the job does not hang.

OGM job (at least #110) is fubar as well.  It is just sitting there
spinning.  The console shows absolutely nothing.  Its been in that state
for "Started 9 hr 48 min ago" as of the time I write this.

From sanne at hibernate.org  Fri Apr  4 07:54:30 2014
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 4 Apr 2014 12:54:30 +0100
Subject: [hibernate-dev] CI environment
In-Reply-To: <CAFdSV9t5jS24y7CQV3B5ubOgHByu-1Tvs=8yoA_oUfC7SnR31Q@mail.gmail.com>
References: <CAFdSV9t5jS24y7CQV3B5ubOgHByu-1Tvs=8yoA_oUfC7SnR31Q@mail.gmail.com>
Message-ID: <CAFm4XO0-gjro5d_16WoSVNXkvbcgNVARuNv6QLWN7gYCoWv_kQ@mail.gmail.com>

I did a bit of maintenance while looking at the OGM job.
It looks like that the OGM jobs actually finish in a reasonable time,
but the status is not being reported, or the workspace was containing
dirt marker files; I nuked job #110 's working directory to cleanup.

It looks like that OGM somehow bypasses the locking system; I suspect
because it uses the Axis plugin to spawn multiple sub-jobs.
So it might still run in parallel with other jobs for which it really
should not (as it might conflict ports). Not sure what to to about
that, as I'm not going to debug the Jenkins plugins. I'll move it all
to the new server using Docker for full isolation as soon as I get
back from travels this month.

# Java 8
I disabled all the builds using the Java 8 previews, and created new
fresh clones for:
- Hibernate Validator
- Hibernate Search
- Hibernate OGM

to use the Java 8 Final release.

I'll keep the disabled jobs around for a while as reference, in case
someone needs to have a look, but we'll eventually delete these.
@Gunnar: there is a "private job" of yours in this category: you still
need it? I disabled it.

I didn't create one for ORM because it doesn't work yet.

Sanne


On 4 April 2014 01:48, Steve Ebersole <steve at hibernate.org> wrote:
> There is something very very funky going on in the CI environment.
>
> The ORM master job hangs almost every run now.  Oddly, it hangs trying to
> compile test classes. I have tried a number of things in attempt to find
> out why.  I have added `strace` to the job command, ssh'iong to the box and
> manually watching processes.  None of this has illuminated the cause for
> me.  Interestingly, I tried using Gradle's --debug option but then of
> course the job does not hang.
>
> OGM job (at least #110) is fubar as well.  It is just sitting there
> spinning.  The console shows absolutely nothing.  Its been in that state
> for "Started 9 hr 48 min ago" as of the time I write this.
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From gunnar at hibernate.org  Fri Apr  4 09:06:23 2014
From: gunnar at hibernate.org (Gunnar Morling)
Date: Fri, 4 Apr 2014 15:06:23 +0200
Subject: [hibernate-dev] CI environment
In-Reply-To: <CAFm4XO0-gjro5d_16WoSVNXkvbcgNVARuNv6QLWN7gYCoWv_kQ@mail.gmail.com>
References: <CAFdSV9t5jS24y7CQV3B5ubOgHByu-1Tvs=8yoA_oUfC7SnR31Q@mail.gmail.com>
	<CAFm4XO0-gjro5d_16WoSVNXkvbcgNVARuNv6QLWN7gYCoWv_kQ@mail.gmail.com>
Message-ID: <CADGJaX-PMS8JoMX9NW6VgDjyAYznmzsxY3dZozKL3ogK3dXrVQ@mail.gmail.com>

2014-04-04 13:54 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:

> I did a bit of maintenance while looking at the OGM job.
> It looks like that the OGM jobs actually finish in a reasonable time,
> but the status is not being reported, or the workspace was containing
> dirt marker files; I nuked job #110 's working directory to cleanup.
>
> It looks like that OGM somehow bypasses the locking system; I suspect
> because it uses the Axis plugin to spawn multiple sub-jobs.
> So it might still run in parallel with other jobs for which it really
> should not (as it might conflict ports). Not sure what to to about
> that, as I'm not going to debug the Jenkins plugins. I'll move it all
> to the new server using Docker for full isolation as soon as I get
> back from travels this month.
>

I think we can replace the Matrix job with a normal Maven job.

The matrix stuff is only done to run the MongoDB tests once against a
separately started instance and once against an instance started via a
Maven plug-in. That's not really necessary as the DB behaves exactly the
same in both cases, so we should be fine by just using the separate DB.

>
> # Java 8
> I disabled all the builds using the Java 8 previews, and created new
> fresh clones for:
> - Hibernate Validator
> - Hibernate Search
> - Hibernate OGM
>
> to use the Java 8 Final release.
>
> I'll keep the disabled jobs around for a while as reference, in case
> someone needs to have a look, but we'll eventually delete these.
> @Gunnar: there is a "private job" of yours in this category: you still
> need it? I disabled it.
>

I've just deleted that job.

>
> I didn't create one for ORM because it doesn't work yet.
>
> Sanne
>

--Gunnar


>
>
> On 4 April 2014 01:48, Steve Ebersole <steve at hibernate.org> wrote:
> > There is something very very funky going on in the CI environment.
> >
> > The ORM master job hangs almost every run now.  Oddly, it hangs trying to
> > compile test classes. I have tried a number of things in attempt to find
> > out why.  I have added `strace` to the job command, ssh'iong to the box
> and
> > manually watching processes.  None of this has illuminated the cause for
> > me.  Interestingly, I tried using Gradle's --debug option but then of
> > course the job does not hang.
> >
> > OGM job (at least #110) is fubar as well.  It is just sitting there
> > spinning.  The console shows absolutely nothing.  Its been in that state
> > for "Started 9 hr 48 min ago" as of the time I write this.
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From emmanuel at hibernate.org  Fri Apr  4 09:27:56 2014
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Fri, 4 Apr 2014 15:27:56 +0200
Subject: [hibernate-dev] On 2nd level cache and requirements off the cache
	implementor
Message-ID: <20140404132756.GR942@hibernate.org>

This is brain storming at this stage.

How much is required of a cache provider as far as semantic is
concerned and be cluster safe? The only providers we currently offer are EhCache and
Infinispan
http://docs.jboss.org/hibernate/orm/4.3/manual/en-US/html_single/#performance-cache

But both happen to be transactional so I wonder if that's a requirement
and if not what are the list of atomic operations that a clustered cache
provider would need to offer.

Any hint and feedback appreciated :)

Emmanuel

From sanne at hibernate.org  Fri Apr  4 11:28:31 2014
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 4 Apr 2014 16:28:31 +0100
Subject: [hibernate-dev] Hibernate Search 5.0.0.Alpha3 now available
Message-ID: <CAFm4XO28LLgzb3Yam=WNW+9N=bbL_PZVsNmhcOK4NwmAqNy8LQ@mail.gmail.com>

Dear all,
another developer milestone is available:

http://in.relation.to/Bloggers/ThirdMilestoneOnThePathForHibernateSearch5

Best,
Sanne

From sanne at hibernate.org  Fri Apr  4 14:13:30 2014
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 4 Apr 2014 19:13:30 +0100
Subject: [hibernate-dev] On 2nd level cache and requirements off the
	cache implementor
In-Reply-To: <20140404132756.GR942@hibernate.org>
References: <20140404132756.GR942@hibernate.org>
Message-ID: <CAFm4XO2QKBk_M_=pc54StDC-urhopzWKmJmQxTN7WRAYoFa0OA@mail.gmail.com>

Both Ehcache and Infinispan support transactions, but Ehcache doesn't
use this capability when running as Hibernate 2nd level cache, while
Infinispan uses it more as an implementation detail to provide
internal consistency, and not to participate with the application
transaction.

So I think that the fact they both happen to also support Transactions
should be considered incidental.

I'd very interested too to hear from Galder and Alex about the
required atomic operation they build on. I could look at the code but
I'm primarily wondering of what they'd rather need conceptually, than
knowing what they are forced to do today.

Sanne

On 4 April 2014 14:27, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
> This is brain storming at this stage.
>
> How much is required of a cache provider as far as semantic is
> concerned and be cluster safe? The only providers we currently offer are EhCache and
> Infinispan
> http://docs.jboss.org/hibernate/orm/4.3/manual/en-US/html_single/#performance-cache
>
> But both happen to be transactional so I wonder if that's a requirement
> and if not what are the list of atomic operations that a clustered cache
> provider would need to offer.
>
> Any hint and feedback appreciated :)
>
> Emmanuel
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From steve at hibernate.org  Fri Apr  4 18:46:24 2014
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 4 Apr 2014 17:46:24 -0500
Subject: [hibernate-dev] ORM master CI config
Message-ID: <CAFdSV9sqAKkT0sUSmZ_MUYEqmanHLzLjc=Q9DNiJSN3YXR+q5A@mail.gmail.com>

The CI jobs for ORM master have been hanging for some unknown reason.
 Following some recommended changes[1] from Peter (one of the Gradle devs)
I have just pushed an updated gradle script for hibernate-core.

This is still in flux.

I wanted to give everyone a heads up in case they start experiencing
problems building after pull.  Let me know if you do.


[1]
http://forums.gradle.org/gradle/topics/gradle_hangs_indefinitely_in_testclasses_ci

From m.schipperheyn at gmail.com  Sat Apr  5 08:34:32 2014
From: m.schipperheyn at gmail.com (Marc Schipperheyn)
Date: Sat, 5 Apr 2014 09:34:32 -0300
Subject: [hibernate-dev] Why Hibernate 4.2.x should receive more updates
Message-ID: <CAGvEgx50NCVSOGLJxYiqfgPjs0OLbFCmvX=TSh+zxq5kq63oQA@mail.gmail.com>

Just wanted to outline some reasons for keeping the Hibernate 4.2.x release
train alive.

I would love to update today to 4.3.x. But I'm on Spring 3.x and the
Hibernate 4.3.x line only made it into Spring 4.x. So everybody using
Spring 3.x will be stuck on 4.2.x. I would say that's prob just about
everybody using Spring. Spring 4 was only recently released.

IMHO this is not on the Spring team but on the fact that a significant
refactoring was executed post Hibernate 4.0.x. The corresponding Spring
JIRA is here SPR-10839 <https://jira.spring.io/browse/SPR-10839>
One idea would be to release an adapter that allows Hibernate to be used
with Spring 3.x. I'll be upgrading to Spring 4 soon, so I only care fore
convenience sake, but I control my IT infra. If you guys want the latest
and greatest Hibernate on all Spring installs this year, you might consider
helping that along a little.

Cheers,
Marc

From gunnar at hibernate.org  Mon Apr  7 08:09:13 2014
From: gunnar at hibernate.org (Gunnar Morling)
Date: Mon, 7 Apr 2014 14:09:13 +0200
Subject: [hibernate-dev] CI environment
In-Reply-To: <CADGJaX-PMS8JoMX9NW6VgDjyAYznmzsxY3dZozKL3ogK3dXrVQ@mail.gmail.com>
References: <CAFdSV9t5jS24y7CQV3B5ubOgHByu-1Tvs=8yoA_oUfC7SnR31Q@mail.gmail.com>
	<CAFm4XO0-gjro5d_16WoSVNXkvbcgNVARuNv6QLWN7gYCoWv_kQ@mail.gmail.com>
	<CADGJaX-PMS8JoMX9NW6VgDjyAYznmzsxY3dZozKL3ogK3dXrVQ@mail.gmail.com>
Message-ID: <CADGJaX8AaMBK=OfeiuN3bNYo81P_g057XQ8Uzeoz5DQBt=3faA@mail.gmail.com>

2014-04-04 15:06 GMT+02:00 Gunnar Morling <gunnar at hibernate.org>:

> 2014-04-04 13:54 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
>
> I did a bit of maintenance while looking at the OGM job.
>> It looks like that the OGM jobs actually finish in a reasonable time,
>> but the status is not being reported, or the workspace was containing
>> dirt marker files; I nuked job #110 's working directory to cleanup.
>>
>> It looks like that OGM somehow bypasses the locking system; I suspect
>> because it uses the Axis plugin to spawn multiple sub-jobs.
>> So it might still run in parallel with other jobs for which it really
>> should not (as it might conflict ports). Not sure what to to about
>> that, as I'm not going to debug the Jenkins plugins. I'll move it all
>> to the new server using Docker for full isolation as soon as I get
>> back from travels this month.
>>
>
> I think we can replace the Matrix job with a normal Maven job.
>
> The matrix stuff is only done to run the MongoDB tests once against a
> separately started instance and once against an instance started via a
> Maven plug-in. That's not really necessary as the DB behaves exactly the
> same in both cases, so we should be fine by just using the separate DB.
>

I've disabled the old Matrix jobs for OGM and created two new jobs (one for
master and one for PRs) which build nicely now.

# Java 8
>> I disabled all the builds using the Java 8 previews, and created new
>> fresh clones for:
>> - Hibernate Validator
>> - Hibernate Search
>> - Hibernate OGM
>>
>> to use the Java 8 Final release.
>>
>> I'll keep the disabled jobs around for a while as reference, in case
>> someone needs to have a look, but we'll eventually delete these.
>> @Gunnar: there is a "private job" of yours in this category: you still
>> need it? I disabled it.
>>
>
> I've just deleted that job.
>
>>
>> I didn't create one for ORM because it doesn't work yet.
>>
>> Sanne
>>
>
> --Gunnar
>
>
>>
>>
>> On 4 April 2014 01:48, Steve Ebersole <steve at hibernate.org> wrote:
>> > There is something very very funky going on in the CI environment.
>> >
>> > The ORM master job hangs almost every run now.  Oddly, it hangs trying
>> to
>> > compile test classes. I have tried a number of things in attempt to find
>> > out why.  I have added `strace` to the job command, ssh'iong to the box
>> and
>> > manually watching processes.  None of this has illuminated the cause for
>> > me.  Interestingly, I tried using Gradle's --debug option but then of
>> > course the job does not hang.
>> >
>> > OGM job (at least #110) is fubar as well.  It is just sitting there
>> > spinning.  The console shows absolutely nothing.  Its been in that state
>> > for "Started 9 hr 48 min ago" as of the time I write this.
>> > _______________________________________________
>> > hibernate-dev mailing list
>> > hibernate-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>

From steve at hibernate.org  Mon Apr  7 11:27:37 2014
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 7 Apr 2014 10:27:37 -0500
Subject: [hibernate-dev] Metamodel - Entity primary key mappings
Message-ID: <CAFdSV9to5AxoMKQAsBqY0qW5Jbz2480TVQ-eeAMHPfnfBwHGQA@mail.gmail.com>

I've been spending a lot of time the last 2 weeks trying to get a good
"mental model" as to how to best model the information pertaining to an
entity's primary key.  Most of this effort went into trying to understand
JPA's "derived identity" support.

First and foremost I want to get away from modelling this (in the
metamodel) as a singular attribute. This is unnatural in the
"non-aggregated composite id" case forcing us to build a "virtual"
attribute.  I think that this is very doable with the distinction I
recently added to the metamodel between Embedded/Embeddable.

Next is to finish up support for IdClass, which should be close to done.
 Gail, I know you had mentioned a case where that support was lacking.
 Could you send me the specifics so I make sure we get that case covered?

Beyond that is mainly incorporating support for JPA "derived identities".
 With that, I want to share some of my understanding and see if I missed
anything...

"Derived identity" support is essentially Hibernate's much older "foreign"
identifier generator, namely that the child entity gets (all of or part of)
its identifier from a to-one association defined on it, from its "foreign
key" value.  But of course the spec verbosely covers all the ways this
might happen.

The very first thing I noticed is that the examples in the spec come in 2
distinct top-level flavors.  Examples 1-3 are cases where the "parent id"
is simply part of the "derived (child) id".  Examples 4-6 are cases where
the parent id *is* the child id (shared pk).  I am not sure how important
this distinction is in practice, but I also noticed that @MapsId is only
pertinent wrt the second set of cases where we have the shared pk.  This
was the first time I have noticed that distinction.

The one monkey wrench that JPA throws into the works here is that there are
essentially multiple views of an entity's PK.  As one example, take the
spec's "Example 4.a":

@Entity
public class Person {
  @Id String ssn;
  ...
}

@Entity
public class MedicalHistory {
  @Id
  @OneToOne
  @JoinColumn(name="FK")
  Person patient;
  ...
}

Ultimately, the primary key of MedicalHistory is the `ssn` of its
associated Person.  Thus both of these are valid:

entityManager.find( MedicalHistory.class, somePerson );
entityManager.find( MedicalHistory.class, somePerson.ssn );

For those who have seen it, this is the reason for the wonkiness inside
Hibernate's runtime engine wrt incoming id type while doing a load.


I am still going through all the use cases (ours plus JPA) to make sure we
get everything covered.  But I wanted to hopefully get some discussion
started around this and get any thoughts y'all might have.

From steve at hibernate.org  Mon Apr  7 11:47:26 2014
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 7 Apr 2014 10:47:26 -0500
Subject: [hibernate-dev] Why Hibernate 4.2.x should receive more updates
In-Reply-To: <CAGvEgx50NCVSOGLJxYiqfgPjs0OLbFCmvX=TSh+zxq5kq63oQA@mail.gmail.com>
References: <CAGvEgx50NCVSOGLJxYiqfgPjs0OLbFCmvX=TSh+zxq5kq63oQA@mail.gmail.com>
Message-ID: <CAFdSV9szSjNzc4f-fb1948zbxvx0=p_sOV2-mtNt4vNncVz_3g@mail.gmail.com>

I simply do not consider Spring a valid reason to keep older Hibernate
release families active.  So to say its "not on the Spring team" and imply
it is all Hibernate's problem is a bit misleading.  Early in
Spring/Hibernate integration they used to work with us to flesh out
integration points.  Of course they would have, they were looking for
traction as a new project and wanted to ride on Hibernate's popularity.
 Since then, not only have they stopped reaching out to us, but in a few
cases were I reached out to them and offered suggestions on how to do
certain integrations I was ignored.  So yes, in some ways it is on them.

To me, if anything, a far more compelling reason would be JPA 2.0 (4.2)
versus JPA 2.1 (4.3) support.

However, you need to understand that this is an open source project.  We
simply do not have the man power that commercial offerings do.  Us being
able to keep up development and testing of all these "dead" branches is
simply not feasible.


On Sat, Apr 5, 2014 at 7:34 AM, Marc Schipperheyn
<m.schipperheyn at gmail.com>wrote:

> Just wanted to outline some reasons for keeping the Hibernate 4.2.x release
> train alive.
>
> I would love to update today to 4.3.x. But I'm on Spring 3.x and the
> Hibernate 4.3.x line only made it into Spring 4.x. So everybody using
> Spring 3.x will be stuck on 4.2.x. I would say that's prob just about
> everybody using Spring. Spring 4 was only recently released.
>
> IMHO this is not on the Spring team but on the fact that a significant
> refactoring was executed post Hibernate 4.0.x. The corresponding Spring
> JIRA is here SPR-10839 <https://jira.spring.io/browse/SPR-10839>
> One idea would be to release an adapter that allows Hibernate to be used
> with Spring 3.x. I'll be upgrading to Spring 4 soon, so I only care fore
> convenience sake, but I control my IT infra. If you guys want the latest
> and greatest Hibernate on all Spring installs this year, you might consider
> helping that along a little.
>
> Cheers,
> Marc
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From m.schipperheyn at gmail.com  Mon Apr  7 12:58:23 2014
From: m.schipperheyn at gmail.com (Marc Schipperheyn)
Date: Mon, 7 Apr 2014 13:58:23 -0300
Subject: [hibernate-dev] Why Hibernate 4.2.x should receive more updates
In-Reply-To: <CAFdSV9szSjNzc4f-fb1948zbxvx0=p_sOV2-mtNt4vNncVz_3g@mail.gmail.com>
References: <CAGvEgx50NCVSOGLJxYiqfgPjs0OLbFCmvX=TSh+zxq5kq63oQA@mail.gmail.com>
	<CAFdSV9szSjNzc4f-fb1948zbxvx0=p_sOV2-mtNt4vNncVz_3g@mail.gmail.com>
Message-ID: <CAGvEgx6=qxFFsLyAXvDPKJ_6zn9MtFDNHSyTJ8uvv1qDGQVrSA@mail.gmail.com>

Fair enough. It's a shame though. Like it or not, there are tons of people
using Spring and I'm guessing the vast majority will not be on 4.0 any time
soon, even though they might want to. So, this will certainly impact the
uptake of Hibernate latest version (including the amount of bug reports
against the newer version you will receive which will indirectly impact
quality etc). I was suggesting that it might make "business sense" to keep
the support but I totally understand the need to optimize the use of
resources.

From m.schipperheyn at gmail.com  Mon Apr  7 13:03:15 2014
From: m.schipperheyn at gmail.com (Marc Schipperheyn)
Date: Mon, 7 Apr 2014 14:03:15 -0300
Subject: [hibernate-dev] Ology, a social network running on Hibernate
Message-ID: <CAGvEgx6wog+ShHxSzjO2ME0fJiNiVFJdVZPffqcPEwjEL-dpjw@mail.gmail.com>

Hi all,

On another note I just wanted to mention the new release of Ology,
www.ology.com.br.
It's a social network that can be seen as a mix between Facebook and
LinkedIn exclusively for physicians that runs on Spring, Hibernate,
Hibernate Search, YUI. Although this is not a technical topic, and I
certainly don't intend to spam, I thought it might interest some people to
see this kind of platform running on Hibernate.

Cheers,
Marc

From brmeyer at redhat.com  Mon Apr  7 15:05:36 2014
From: brmeyer at redhat.com (Brett Meyer)
Date: Mon, 7 Apr 2014 15:05:36 -0400 (EDT)
Subject: [hibernate-dev] "Stale" Hibernate issues
In-Reply-To: <CAB63Y-eMw7PR3yVDs5fkX_FbKD48ZVTfnaEQsB91DuJ0+Vrq5A@mail.gmail.com>
References: <CAB63Y-eMw7PR3yVDs5fkX_FbKD48ZVTfnaEQsB91DuJ0+Vrq5A@mail.gmail.com>
Message-ID: <612195797.1056063.1396897536358.JavaMail.zimbra@redhat.com>

Hi Martijn, I'm CC'ing the mailing list -- there are a few misconceptions I'd like to clear up for everyone.

First and foremost, statements like "But nobody from the Hibernate has ever taken a look" are frankly frustrating.  Hibernate is an open source project, not a proprietary product with separated groups of consumers and producers.  We all have our own interests and priorities.  If HHH-3930 is important for someone, pull requests or patches would be fantastic and much appreciated by the community!

Your point argues against itself.  There are so many issues that deserve the community's attention, and HHH-3930 is no different from the rest.  But due to the sheer amount of open tickets, it was getting impossible to sort through them all.  We have to do *something* to narrow it down, and this was the best solution we could find.

Everyone, please keep in mind that if an issue is still valid on ORM 4, simply say so in a comment.  I'm more than happy to re-open them on a case-by-case basis.  An aggressive approach was necessary -- simply letting thousands of tickets sit there is, imho, much worse.

Regarding the development of test cases, we've said from the beginning that, although we certainly prefer runnable cases (either standalone or extending an existing unit test), I've always thought that enough detail in the description (entities, mappings, applicable settings, and code snippets) were perfectly acceptable and definitely making a big attempt at helping out.  That hasn't changed.  However, several people have mentioned wishing for a template project to use in creating standalone reproducers -- that's a great idea.  I'm planning on putting one together soon and will share it.

Brett Meyer
Red Hat, Hibernate ORM

----- Original Message -----
From: "Martijn Dashorst" <martijn.dashorst at gmail.com>
To: brmeyer at redhat.com
Sent: Monday, April 7, 2014 2:41:20 PM
Subject: "Stale" Hibernate issues

Dear Brett,

I understand the necessity of sorting out stale issues in a large project
as Hibernate, but blindly shafting folks that are waiting 5 years for a
proper response from the hibernate team is not the way to go.

Case in point: HHH-3930 has been open for 5 years, has provided a clear
description and code for two entities afflicted entities. But nobody from
the Hibernate has ever taken a look and commented on it for specific
information.

Only canned responses from mass updates have been provided.

I urge you to actually look at this issue and give proper feedback on what
is needed for it to be considered.

If the information is incomplete, or the report unclear, say so.

IMO you can only require folks adding a test case if you have a decent
guide of how to write one. Provide a maven archetype for it.

Requiring folks to have to checkout the hibernate project, figure out the
coding guidelines, having to peruse the test cases to figure out what to do
is really stretching it.

You state that you don't want to come across as arrogant, but from my
standpoint, the current actions actually make me wish I never had filed the
issue and just work around it, polluting my model and never going to file a
bug report with Hibernate ever again.

Martijn

From brmeyer at redhat.com  Mon Apr  7 17:26:46 2014
From: brmeyer at redhat.com (Brett Meyer)
Date: Mon, 7 Apr 2014 17:26:46 -0400 (EDT)
Subject: [hibernate-dev] "Stale" Hibernate issues
In-Reply-To: <CAB63Y-cjYezwmt_FWWy8Heo4TKxyWQPvJ1hcme6k5nzJgm8pSg@mail.gmail.com>
References: <CAB63Y-eMw7PR3yVDs5fkX_FbKD48ZVTfnaEQsB91DuJ0+Vrq5A@mail.gmail.com>
	<612195797.1056063.1396897536358.JavaMail.zimbra@redhat.com>
	<CAB63Y-cjYezwmt_FWWy8Heo4TKxyWQPvJ1hcme6k5nzJgm8pSg@mail.gmail.com>
Message-ID: <256945113.1137865.1396906006397.JavaMail.zimbra@redhat.com>

But Martijn, you're still missing my main points.

"...awaiting a response from the core team..."
"...without any evidence of a core member looking at the issue..."
"...your users..."

You're still thinking of this community in a proprietary product sense.  It's not.  The core team is small and focused.  All individual contributors work on what they're most interested in or the biggest priority in their environment.  If you have an issue that's important/urgent for you, then take a stab at fixing it!  If everyone had that attitude within open source communities, some incredible things would result.  Directly emailing the core team members, complaining that they haven't given your specific issue enough attention isn't going to accomplish anything.  But that's certainly not to say that the core team is hands off.  We all work hard.  Really hard.  And if something critical comes up, it's usually pounced on promptly.

Before I started tackling the state of our JIRA instance, there were over 3k unresolved issues.  Like I've already mentioned all over the place, that's not indicative of quality.  It simply stems from a complex, 10+ year old project with thousands of users.  When that many issues are open, it is *impossible* to identify what's still an issue.  Going through them one-by-one is not even remotely reasonable.  The policies we're trying to enforce are not simply to assist the core team, but the community as a whole.  Imagine someone who is interested in getting started with contributing to ORM.  If they pull up JIRA, how in the world would they know where to start?

I will most definitely take a look at your project in HHH-9105 and roll something out for everyone to use as needed.  Thanks for that.  I'm definitely up for any more *constructive* ideas/feedback.

Brett Meyer
Red Hat, Hibernate ORM

----- Original Message -----
From: "Martijn Dashorst" <martijn.dashorst at gmail.com>
To: "Brett Meyer" <brmeyer at redhat.com>
Cc: "Hibernate" <hibernate-dev at lists.jboss.org>
Sent: Monday, April 7, 2014 4:29:38 PM
Subject: Re: "Stale" Hibernate issues

I know that open source projects are run by volunteers. I appreciate the
efforts folks put in, even if they don't get to look at my issue-especially
when I can work around the issue with a fugly solution, awaiting a response
from the core team.

I don't find my issue super duper important: we were able to work around
it, and we check with every major release if someone has considered solving
it-being disappointed, having a bitter laugh, and continue with our day to
day job.

My issue with the treatment is that after five years of neglect, without
any evidence of a core member looking at the issue, it gets the "give us a
test case or we will close it" treatment, combined with the "we don't want
to look arrogant" attitude.

There's a quid-pro-quo: if you ask your users to do something for you, you
have to give something in return. As a user I have done quite a lot:
described the issue I found in detail, provided mappings. Multiple users
have reported the same behaviour, even in a 4.0-beta.

Given that nobody from the core hibernate team has ever commented on the
issue, I do remain with my opinion that the issue has not been taken
seriously, giving me-a user who has put effort into reporting with proper
detail what the issue is-the willies of ever reporting an issue with
Hibernate again.

So I have gone about and had to shave a yak or two to actually reproduce
the issue at hand (creating a hibernate project, setting up a database,
finding the magical incantations to start up a Hibernate configuration),
fixing the logging, etc) taking up my free evening I could have spent on my
own open source project, or socialising with my wife, or etc. All of this
 probably would have taken a core dev about 2 minutes given that you have
the environment setup and know your testing framework in and out.

So I will comment on HHH-3930 that the issue is still present in Hibernate
4.3.5, and also create a new issue with an empty test case which you can
incorporate into your bug reporting template as a test case builder for
folks reporting bugs. I hope you will incorporate this into your project
and save everybody hours of time.

See https://hibernate.atlassian.net/browse/HHH-9105 for the setup. It uses
one deprecated API (config.buildSessionFactory()), but I figure you can
improve upon this easily.

This is also easily converted to a Maven archetype that can be generated
with your normal release cycle. You can then create a online wizard that
allows folks to quickly generate a quick start based on a specific version
of Hibernate. See for example
http://wicket.apache.org/start/quickstart.htmlfor such a page, and
https://github.com/apache/wicket/tree/master/archetypes/quickstart for the
implementation of that archetype.

Martijn




On Mon, Apr 7, 2014 at 9:05 PM, Brett Meyer <brmeyer at redhat.com> wrote:

> Hi Martijn, I'm CC'ing the mailing list -- there are a few misconceptions
> I'd like to clear up for everyone.
>
> First and foremost, statements like "But nobody from the Hibernate has
> ever taken a look" are frankly frustrating.  Hibernate is an open source
> project, not a proprietary product with separated groups of consumers and
> producers.  We all have our own interests and priorities.  If HHH-3930 is
> important for someone, pull requests or patches would be fantastic and much
> appreciated by the community!
>
> Your point argues against itself.  There are so many issues that deserve
> the community's attention, and HHH-3930 is no different from the rest.  But
> due to the sheer amount of open tickets, it was getting impossible to sort
> through them all.  We have to do *something* to narrow it down, and this
> was the best solution we could find.
>
> Everyone, please keep in mind that if an issue is still valid on ORM 4,
> simply say so in a comment.  I'm more than happy to re-open them on a
> case-by-case basis.  An aggressive approach was necessary -- simply letting
> thousands of tickets sit there is, imho, much worse.
>
> Regarding the development of test cases, we've said from the beginning
> that, although we certainly prefer runnable cases (either standalone or
> extending an existing unit test), I've always thought that enough detail in
> the description (entities, mappings, applicable settings, and code
> snippets) were perfectly acceptable and definitely making a big attempt at
> helping out.  That hasn't changed.  However, several people have mentioned
> wishing for a template project to use in creating standalone reproducers --
> that's a great idea.  I'm planning on putting one together soon and will
> share it.
>
> Brett Meyer
> Red Hat, Hibernate ORM
>
> ----- Original Message -----
> From: "Martijn Dashorst" <martijn.dashorst at gmail.com>
> To: brmeyer at redhat.com
> Sent: Monday, April 7, 2014 2:41:20 PM
> Subject: "Stale" Hibernate issues
>
> Dear Brett,
>
> I understand the necessity of sorting out stale issues in a large project
> as Hibernate, but blindly shafting folks that are waiting 5 years for a
> proper response from the hibernate team is not the way to go.
>
> Case in point: HHH-3930 has been open for 5 years, has provided a clear
> description and code for two entities afflicted entities. But nobody from
> the Hibernate has ever taken a look and commented on it for specific
> information.
>
> Only canned responses from mass updates have been provided.
>
> I urge you to actually look at this issue and give proper feedback on what
> is needed for it to be considered.
>
> If the information is incomplete, or the report unclear, say so.
>
> IMO you can only require folks adding a test case if you have a decent
> guide of how to write one. Provide a maven archetype for it.
>
> Requiring folks to have to checkout the hibernate project, figure out the
> coding guidelines, having to peruse the test cases to figure out what to do
> is really stretching it.
>
> You state that you don't want to come across as arrogant, but from my
> standpoint, the current actions actually make me wish I never had filed the
> issue and just work around it, polluting my model and never going to file a
> bug report with Hibernate ever again.
>
> Martijn
>



-- 
Become a Wicket expert, learn from the best: http://wicketinaction.com

From alex.snaps at gmail.com  Mon Apr  7 17:32:05 2014
From: alex.snaps at gmail.com (Alex Snaps)
Date: Mon, 7 Apr 2014 17:32:05 -0400
Subject: [hibernate-dev] On 2nd level cache and requirements off the
	cache implementor
In-Reply-To: <CAFm4XO2QKBk_M_=pc54StDC-urhopzWKmJmQxTN7WRAYoFa0OA@mail.gmail.com>
References: <20140404132756.GR942@hibernate.org>
	<CAFm4XO2QKBk_M_=pc54StDC-urhopzWKmJmQxTN7WRAYoFa0OA@mail.gmail.com>
Message-ID: <CAKux6pb+rH-Y76e9BNiO2mwkGKq=GgLg=uhrSUN9vVX-ccfqnA@mail.gmail.com>

Y, Ehcache will work clustered both in transactional (JTA), read-only and
read-write just fine (non strict will work, only blows the race wider open
and inconsistent data will be noticed "quicker").
Am trying to think hard what a cache provider "conceptually needs" to
support clustered scenarios. One could argue clustered is merely doing
stuff over the wires rather than on the mem bus.
So I guess a strongly consistent mode, with some coordination primitives (a
synchronous API of some kind could well be enough I think). Actually
implementing the READ_WRITE strategy on top of jsr107 should give some
perspectives. Today, Ehcache resorts to explicit locks in read_write, but
entry processors should fit the bill just as much (until I'm proven wrong
obviously!). Transactional caches abstract that complexity from the H2LC
provider code, but the coordination still exists (and actually does more
too, as it also provide isolation and JTA recovery in our case as well).
Is this some meaningful input ? Willing to discuss this further though...

PS: Sorry for replying only now, had the pleasure of being sick for the
last three days :/



On Fri, Apr 4, 2014 at 2:13 PM, Sanne Grinovero <sanne at hibernate.org> wrote:

> Both Ehcache and Infinispan support transactions, but Ehcache doesn't
> use this capability when running as Hibernate 2nd level cache, while
> Infinispan uses it more as an implementation detail to provide
> internal consistency, and not to participate with the application
> transaction.
>
> So I think that the fact they both happen to also support Transactions
> should be considered incidental.
>
> I'd very interested too to hear from Galder and Alex about the
> required atomic operation they build on. I could look at the code but
> I'm primarily wondering of what they'd rather need conceptually, than
> knowing what they are forced to do today.
>
> Sanne
>
> On 4 April 2014 14:27, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
> > This is brain storming at this stage.
> >
> > How much is required of a cache provider as far as semantic is
> > concerned and be cluster safe? The only providers we currently offer are
> EhCache and
> > Infinispan
> >
> http://docs.jboss.org/hibernate/orm/4.3/manual/en-US/html_single/#performance-cache
> >
> > But both happen to be transactional so I wonder if that's a requirement
> > and if not what are the list of atomic operations that a clustered cache
> > provider would need to offer.
> >
> > Any hint and feedback appreciated :)
> >
> > Emmanuel
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>



-- 
Alex Snaps <alex.snaps at gmail.com>
Principal Software Engineer - Terracotta
http://twitter.com/alexsnaps
http://www.linkedin.com/in/alexsnaps
http://withinthefra.me

From sanne at hibernate.org  Mon Apr  7 17:40:54 2014
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 7 Apr 2014 22:40:54 +0100
Subject: [hibernate-dev] "Stale" Hibernate issues
In-Reply-To: <256945113.1137865.1396906006397.JavaMail.zimbra@redhat.com>
References: <CAB63Y-eMw7PR3yVDs5fkX_FbKD48ZVTfnaEQsB91DuJ0+Vrq5A@mail.gmail.com>
	<612195797.1056063.1396897536358.JavaMail.zimbra@redhat.com>
	<CAB63Y-cjYezwmt_FWWy8Heo4TKxyWQPvJ1hcme6k5nzJgm8pSg@mail.gmail.com>
	<256945113.1137865.1396906006397.JavaMail.zimbra@redhat.com>
Message-ID: <CAFm4XO3nPjjY01ZpVUoEbL59Hxv4CuMOC+UMTXXD=4g0xj-PWg@mail.gmail.com>

Good points, we definitely need to make it easier to contribute, be it
just a least resistance path for making a test.

For what it's worth, when I started contributing more seriosly, the
"tipping point" which transformed me from an average user to a
fanatical contributor, was to understand how the testsuite worked. I
know it's not hard at all, but I was assuming that it was hard and so
I hadn't looked as I was assuming that I would not be in an easy
position to provide a working test. For example, I assumed I'd need
all the supported databases setup.

Let's not forget that most users don't ever start Hibernate directly
but get a Session via some framework, so this indeed requires some
research.

I love Martijn's suggestion to upload an archetype with each release;
our first attempt could be very simple, then we take it from there and
maybe provide various mapped entities, a JPA and a native version...

Sanne


On 7 April 2014 22:26, Brett Meyer <brmeyer at redhat.com> wrote:
> But Martijn, you're still missing my main points.
>
> "...awaiting a response from the core team..."
> "...without any evidence of a core member looking at the issue..."
> "...your users..."
>
> You're still thinking of this community in a proprietary product sense.  It's not.  The core team is small and focused.  All individual contributors work on what they're most interested in or the biggest priority in their environment.  If you have an issue that's important/urgent for you, then take a stab at fixing it!  If everyone had that attitude within open source communities, some incredible things would result.  Directly emailing the core team members, complaining that they haven't given your specific issue enough attention isn't going to accomplish anything.  But that's certainly not to say that the core team is hands off.  We all work hard.  Really hard.  And if something critical comes up, it's usually pounced on promptly.
>
> Before I started tackling the state of our JIRA instance, there were over 3k unresolved issues.  Like I've already mentioned all over the place, that's not indicative of quality.  It simply stems from a complex, 10+ year old project with thousands of users.  When that many issues are open, it is *impossible* to identify what's still an issue.  Going through them one-by-one is not even remotely reasonable.  The policies we're trying to enforce are not simply to assist the core team, but the community as a whole.  Imagine someone who is interested in getting started with contributing to ORM.  If they pull up JIRA, how in the world would they know where to start?
>
> I will most definitely take a look at your project in HHH-9105 and roll something out for everyone to use as needed.  Thanks for that.  I'm definitely up for any more *constructive* ideas/feedback.
>
> Brett Meyer
> Red Hat, Hibernate ORM
>
> ----- Original Message -----
> From: "Martijn Dashorst" <martijn.dashorst at gmail.com>
> To: "Brett Meyer" <brmeyer at redhat.com>
> Cc: "Hibernate" <hibernate-dev at lists.jboss.org>
> Sent: Monday, April 7, 2014 4:29:38 PM
> Subject: Re: "Stale" Hibernate issues
>
> I know that open source projects are run by volunteers. I appreciate the
> efforts folks put in, even if they don't get to look at my issue-especially
> when I can work around the issue with a fugly solution, awaiting a response
> from the core team.
>
> I don't find my issue super duper important: we were able to work around
> it, and we check with every major release if someone has considered solving
> it-being disappointed, having a bitter laugh, and continue with our day to
> day job.
>
> My issue with the treatment is that after five years of neglect, without
> any evidence of a core member looking at the issue, it gets the "give us a
> test case or we will close it" treatment, combined with the "we don't want
> to look arrogant" attitude.
>
> There's a quid-pro-quo: if you ask your users to do something for you, you
> have to give something in return. As a user I have done quite a lot:
> described the issue I found in detail, provided mappings. Multiple users
> have reported the same behaviour, even in a 4.0-beta.
>
> Given that nobody from the core hibernate team has ever commented on the
> issue, I do remain with my opinion that the issue has not been taken
> seriously, giving me-a user who has put effort into reporting with proper
> detail what the issue is-the willies of ever reporting an issue with
> Hibernate again.
>
> So I have gone about and had to shave a yak or two to actually reproduce
> the issue at hand (creating a hibernate project, setting up a database,
> finding the magical incantations to start up a Hibernate configuration),
> fixing the logging, etc) taking up my free evening I could have spent on my
> own open source project, or socialising with my wife, or etc. All of this
>  probably would have taken a core dev about 2 minutes given that you have
> the environment setup and know your testing framework in and out.
>
> So I will comment on HHH-3930 that the issue is still present in Hibernate
> 4.3.5, and also create a new issue with an empty test case which you can
> incorporate into your bug reporting template as a test case builder for
> folks reporting bugs. I hope you will incorporate this into your project
> and save everybody hours of time.
>
> See https://hibernate.atlassian.net/browse/HHH-9105 for the setup. It uses
> one deprecated API (config.buildSessionFactory()), but I figure you can
> improve upon this easily.
>
> This is also easily converted to a Maven archetype that can be generated
> with your normal release cycle. You can then create a online wizard that
> allows folks to quickly generate a quick start based on a specific version
> of Hibernate. See for example
> http://wicket.apache.org/start/quickstart.htmlfor such a page, and
> https://github.com/apache/wicket/tree/master/archetypes/quickstart for the
> implementation of that archetype.
>
> Martijn
>
>
>
>
> On Mon, Apr 7, 2014 at 9:05 PM, Brett Meyer <brmeyer at redhat.com> wrote:
>
>> Hi Martijn, I'm CC'ing the mailing list -- there are a few misconceptions
>> I'd like to clear up for everyone.
>>
>> First and foremost, statements like "But nobody from the Hibernate has
>> ever taken a look" are frankly frustrating.  Hibernate is an open source
>> project, not a proprietary product with separated groups of consumers and
>> producers.  We all have our own interests and priorities.  If HHH-3930 is
>> important for someone, pull requests or patches would be fantastic and much
>> appreciated by the community!
>>
>> Your point argues against itself.  There are so many issues that deserve
>> the community's attention, and HHH-3930 is no different from the rest.  But
>> due to the sheer amount of open tickets, it was getting impossible to sort
>> through them all.  We have to do *something* to narrow it down, and this
>> was the best solution we could find.
>>
>> Everyone, please keep in mind that if an issue is still valid on ORM 4,
>> simply say so in a comment.  I'm more than happy to re-open them on a
>> case-by-case basis.  An aggressive approach was necessary -- simply letting
>> thousands of tickets sit there is, imho, much worse.
>>
>> Regarding the development of test cases, we've said from the beginning
>> that, although we certainly prefer runnable cases (either standalone or
>> extending an existing unit test), I've always thought that enough detail in
>> the description (entities, mappings, applicable settings, and code
>> snippets) were perfectly acceptable and definitely making a big attempt at
>> helping out.  That hasn't changed.  However, several people have mentioned
>> wishing for a template project to use in creating standalone reproducers --
>> that's a great idea.  I'm planning on putting one together soon and will
>> share it.
>>
>> Brett Meyer
>> Red Hat, Hibernate ORM
>>
>> ----- Original Message -----
>> From: "Martijn Dashorst" <martijn.dashorst at gmail.com>
>> To: brmeyer at redhat.com
>> Sent: Monday, April 7, 2014 2:41:20 PM
>> Subject: "Stale" Hibernate issues
>>
>> Dear Brett,
>>
>> I understand the necessity of sorting out stale issues in a large project
>> as Hibernate, but blindly shafting folks that are waiting 5 years for a
>> proper response from the hibernate team is not the way to go.
>>
>> Case in point: HHH-3930 has been open for 5 years, has provided a clear
>> description and code for two entities afflicted entities. But nobody from
>> the Hibernate has ever taken a look and commented on it for specific
>> information.
>>
>> Only canned responses from mass updates have been provided.
>>
>> I urge you to actually look at this issue and give proper feedback on what
>> is needed for it to be considered.
>>
>> If the information is incomplete, or the report unclear, say so.
>>
>> IMO you can only require folks adding a test case if you have a decent
>> guide of how to write one. Provide a maven archetype for it.
>>
>> Requiring folks to have to checkout the hibernate project, figure out the
>> coding guidelines, having to peruse the test cases to figure out what to do
>> is really stretching it.
>>
>> You state that you don't want to come across as arrogant, but from my
>> standpoint, the current actions actually make me wish I never had filed the
>> issue and just work around it, polluting my model and never going to file a
>> bug report with Hibernate ever again.
>>
>> Martijn
>>
>
>
>
> --
> Become a Wicket expert, learn from the best: http://wicketinaction.com
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


From steve at hibernate.org  Mon Apr  7 19:45:18 2014
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 7 Apr 2014 18:45:18 -0500
Subject: [hibernate-dev] Metamodel - Entity primary key mappings
In-Reply-To: <CAFdSV9to5AxoMKQAsBqY0qW5Jbz2480TVQ-eeAMHPfnfBwHGQA@mail.gmail.com>
References: <CAFdSV9to5AxoMKQAsBqY0qW5Jbz2480TVQ-eeAMHPfnfBwHGQA@mail.gmail.com>
Message-ID: <CAFdSV9u9Rs5wJCRD6-_X0JBBA=Fpeq7rJiUDsRswkuQkvW3L1w@mail.gmail.com>

What I am thinking at the moment is to change up
org.hibernate.metamodel.spi.binding.EntityIdentifier to look like:

public class EntityIdentifier {
  private final EntityBinding entityBinding;

  private EntityIdentifierNature nature;
  private IdentifierAttributeBindings attributeBindings;
  private IdClassBinding idClassBinding;
  private Map<String,String> derivedIdMap;
  private IdentifierGenerator generator;
}


1) IdentifierAttributeBindings would play sort of the same role
as org.hibernate.metamodel.spi.binding.EntityIdentifier.EntityIdentifierBinding.
 Essentially it would hold the binding state for each of the identifier
attributes (those marked with @Id or @EmbeddedId).  Still not sure the best
external representation of this.  Exposing a simple
List<SingularAttributeBinding> for all identifier natures versus
specialized IdentifierAttributeBindings for each nature are running a
neck-and-neck race atm.  Thoughts?  Votes?

2) IdClassBinding would be a
specialized org.hibernate.metamodel.spi.binding.EmbeddableBindingContributor
for describing the @IdClass mapping

3) `derivedIdMap` holds the various @MapsId mappings for the entity.  I was
tempted to move this off to IdClassBinding except that @MapsId also refers
to @EmbeddedId attributes.

Thoughts?  Worries?  Concerns?




On Mon, Apr 7, 2014 at 10:27 AM, Steve Ebersole <steve at hibernate.org> wrote:

> I've been spending a lot of time the last 2 weeks trying to get a good
> "mental model" as to how to best model the information pertaining to an
> entity's primary key.  Most of this effort went into trying to understand
> JPA's "derived identity" support.
>
> First and foremost I want to get away from modelling this (in the
> metamodel) as a singular attribute. This is unnatural in the
> "non-aggregated composite id" case forcing us to build a "virtual"
> attribute.  I think that this is very doable with the distinction I
> recently added to the metamodel between Embedded/Embeddable.
>
> Next is to finish up support for IdClass, which should be close to done.
>  Gail, I know you had mentioned a case where that support was lacking.
>  Could you send me the specifics so I make sure we get that case covered?
>
> Beyond that is mainly incorporating support for JPA "derived identities".
>  With that, I want to share some of my understanding and see if I missed
> anything...
>
> "Derived identity" support is essentially Hibernate's much older "foreign"
> identifier generator, namely that the child entity gets (all of or part of)
> its identifier from a to-one association defined on it, from its "foreign
> key" value.  But of course the spec verbosely covers all the ways this
> might happen.
>
> The very first thing I noticed is that the examples in the spec come in 2
> distinct top-level flavors.  Examples 1-3 are cases where the "parent id"
> is simply part of the "derived (child) id".  Examples 4-6 are cases where
> the parent id *is* the child id (shared pk).  I am not sure how important
> this distinction is in practice, but I also noticed that @MapsId is only
> pertinent wrt the second set of cases where we have the shared pk.  This
> was the first time I have noticed that distinction.
>
> The one monkey wrench that JPA throws into the works here is that there
> are essentially multiple views of an entity's PK.  As one example, take the
> spec's "Example 4.a":
>
> @Entity
> public class Person {
>   @Id String ssn;
>   ...
> }
>
> @Entity
> public class MedicalHistory {
>   @Id
>   @OneToOne
>   @JoinColumn(name="FK")
>   Person patient;
>   ...
> }
>
> Ultimately, the primary key of MedicalHistory is the `ssn` of its
> associated Person.  Thus both of these are valid:
>
> entityManager.find( MedicalHistory.class, somePerson );
> entityManager.find( MedicalHistory.class, somePerson.ssn );
>
> For those who have seen it, this is the reason for the wonkiness inside
> Hibernate's runtime engine wrt incoming id type while doing a load.
>
>
> I am still going through all the use cases (ours plus JPA) to make sure we
> get everything covered.  But I wanted to hopefully get some discussion
> started around this and get any thoughts y'all might have.
>
>
>

From martijn.dashorst at gmail.com  Mon Apr  7 19:51:35 2014
From: martijn.dashorst at gmail.com (Martijn Dashorst)
Date: Tue, 8 Apr 2014 01:51:35 +0200
Subject: [hibernate-dev] "Stale" Hibernate issues
In-Reply-To: <256945113.1137865.1396906006397.JavaMail.zimbra@redhat.com>
References: <CAB63Y-eMw7PR3yVDs5fkX_FbKD48ZVTfnaEQsB91DuJ0+Vrq5A@mail.gmail.com>
	<612195797.1056063.1396897536358.JavaMail.zimbra@redhat.com>
	<CAB63Y-cjYezwmt_FWWy8Heo4TKxyWQPvJ1hcme6k5nzJgm8pSg@mail.gmail.com>
	<256945113.1137865.1396906006397.JavaMail.zimbra@redhat.com>
Message-ID: <CAB63Y-c3EVOqnt+Hnnxb+Vp6MyX_HfRDrTV2JicSmDdmfS11Cg@mail.gmail.com>

Please bear with me, it's 1:45am and someone on the internet is wrong :-).

Somehow this triggered a knee-jerk reaction to an issue that is rather
minor, hasn't bothered me in months (every now and then I come across the
comment in our source code that references this particular hibernate issue,
and check the progress), and even when I go look at the status, I just
notice the time passed since its reporting and go on my merry way.

While it was not your intention, I guess the canned response to the issue
triggered my anti-something response.

For now this has taken more energy from myself, and probably you, so I
apologise for reacting the way I did.

For completeness sake, a IMO more subtle canned response would be (a bit
long, but hey, it's 1:45am):

"Hi, we thank you for reporting this issue. We are sorry that this issue is
still unresolved after all this time.

Our current backlog of unresolved issues is over 3000 items. While we do
our best to help our community, we are unable to address each of those 3000
issues ourselves. So we kindly ask you to lend us a hand in cleaning up our
backlog of issues: we ask you to check if this issue is still a problem for
Hibernate ORM 4.

If you are able to reproduce the issue in the current version of Hibernate,
please note the steps you took to replicate the unexpected behaviour in a
comment to this issue. It would be awesome if you can provide a test case
(see ... for more information on writing test cases).

This issue was selected because it had few votes, few participants and was
reported against a rather old version of Hibernate. If you don't respond to
this issue in a couple months, we will assume that this issue is no longer
a problem.

We thank you for your time and hope to resolve this issue soon.
"

IMO this would remove any possibility for coming across as arrogant or non
attentive. It shows the real issue, and asks for help. It also provides a
non-committed way to resolve the issue (reproduce it and we will look at it
because we now have time to do so, and know at which issues to look, or we
assume it is solved because nobody else was interested in it since a long
time). Note that this response does not promise to actually solve the
issue, but merely resolve it.

I will most definitely take a look at your project in HHH-9105 and roll
> something out for everyone to use as needed.  Thanks for that.  I'm
> definitely up for any more *constructive* ideas/feedback.
>

That is why I submitted it. Enjoy toying with it and I hope it will bring
many usable test cases.

Martijn

From gbadner at redhat.com  Tue Apr  8 02:50:15 2014
From: gbadner at redhat.com (Gail Badner)
Date: Tue, 8 Apr 2014 02:50:15 -0400 (EDT)
Subject: [hibernate-dev] HHH-9106: Multiple detached representations of the
 same entity cannot be merged
In-Reply-To: <470400114.1950824.1396939092057.JavaMail.zimbra@redhat.com>
Message-ID: <2144416894.1966610.1396939815146.JavaMail.zimbra@redhat.com>

After fixing HHH-6848, Hibernate throws IllegalStateException when merging entity 'x' if it has references to 2 detached entities 'y1' and 'y2' obtained from different sessions, and y1 and y2 represent the same persistent entity. In other words, y1 != y2.

I've pushed some FailureExpected test cases to org.hibernate.test.ops.MergeTest that illustrate this. [1]

Before fixing HHH-6848, one of the representations would be merged and the other would be ignored (probably overwritten). 

I'm looking into a fix that will restore this functionality as well as provide logging for this situation. I'll discuss logging in a separate email.

Merging multiple representations that have equivalent state would be straightforward. Things are more complicated when the representations do not have equivalent state. I'd like to discuss and get feedback before fixing this.

I am a little leery about allowing multiple representations that are not equivalent to be merged because data could be lost. I would prefer to throw an exception by default, and then provide a flag to override this behavior as suggested in HHH-8570. I discussed briefly with Steve E., and he preferred to address this concern by logging a warning. Opinions?

In any case, here are 2 possible strategies:

1) The last one copied will "win". First, the state from one will be copied onto a pre-existing managed entity or a new managed copy, then later when the merge operation is cascaded to the other representation, a copy of its state will overwrite the managed entity state.

2) The first representation detected will "win". The idea here is that y1 and y2 are both representations of the same entity; only 1 can be merged. When the first is detected, the merge operation is cascaded to its associations with cascade=MERGE or cascade=AL, then its state will be copied onto a pre-existing managed entity or a new managed copy. When a later representation is detected, it's state is not copied and the merge operation is not cascaded to its associations with cascade=MERGE or cascade=ALL.

I think 2) fits in better With the way merge currently works.

A problem with 1) is that we won't know when we are processing the last representation until all cascade-merges are finished. By then, the session may contain entities from cascading the merge operation from the earlier representations. This could result in persisting transient entities or updating entites that are only  associated with earlier representations.

With 2) we always know when we are processing the first representation and can more easily skip cascading the merge operation for representations detected later.

Comments?

Thanks,
Gail

[1] https://github.com/hibernate/hibernate-orm/blob/0118376f8efd9b35d8be815c892f3ac7f9b6048f/hibernate-core/src/test/java/org/hibernate/test/ops/MergeTest.java#L829

From emmanuel at hibernate.org  Tue Apr  8 08:52:32 2014
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Tue, 8 Apr 2014 14:52:32 +0200
Subject: [hibernate-dev] Ology, a social network running on Hibernate
In-Reply-To: <CAGvEgx6wog+ShHxSzjO2ME0fJiNiVFJdVZPffqcPEwjEL-dpjw@mail.gmail.com>
References: <CAGvEgx6wog+ShHxSzjO2ME0fJiNiVFJdVZPffqcPEwjEL-dpjw@mail.gmail.com>
Message-ID: <588C2812-CEC8-443F-B938-7AA1FC81E0BF@hibernate.org>

Sweet :)

On 07 Apr 2014, at 19:03, Marc Schipperheyn <m.schipperheyn at gmail.com> wrote:

> Hi all,
> 
> On another note I just wanted to mention the new release of Ology,
> www.ology.com.br.
> It's a social network that can be seen as a mix between Facebook and
> LinkedIn exclusively for physicians that runs on Spring, Hibernate,
> Hibernate Search, YUI. Although this is not a technical topic, and I
> certainly don't intend to spam, I thought it might interest some people to
> see this kind of platform running on Hibernate.
> 
> Cheers,
> Marc
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


From brmeyer at redhat.com  Tue Apr  8 16:45:37 2014
From: brmeyer at redhat.com (Brett Meyer)
Date: Tue, 8 Apr 2014 16:45:37 -0400 (EDT)
Subject: [hibernate-dev] Hibernate ORM 4.2.12.Final Released
Message-ID: <1150832658.2123955.1396989937698.JavaMail.zimbra@redhat.com>

Due to a regression and a few important fixes, we decided to release another 4.2.x.  For more info, please see: http://in.relation.to/Bloggers/HibernateORM4212FinalReleased

Brett Meyer
Red Hat, Hibernate ORM


From emmanuel at hibernate.org  Wed Apr  9 07:32:51 2014
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Wed, 9 Apr 2014 13:32:51 +0200
Subject: [hibernate-dev] HHH-9106: Multiple detached representations of
 the same entity cannot be merged
In-Reply-To: <2144416894.1966610.1396939815146.JavaMail.zimbra@redhat.com>
References: <470400114.1950824.1396939092057.JavaMail.zimbra@redhat.com>
	<2144416894.1966610.1396939815146.JavaMail.zimbra@redhat.com>
Message-ID: <20140409113251.GA5788@hibernate.org>

I have had a chat with Gail on $subject and promised to give my
feedback.

First of, I would argue that the user is doing something relatively
wrong on my weirdo scale. I am not massively bothered with whatever
solution we end up choosing.

When the same state is present in both instances, you guys agreed to
consider it a no-op which Ia gree offers the best user experience.

About warn vs exception, I would prefer warn or even nothing (see below)
but I can see the benefit of a pluggable strategy.

Now the big questions are:

1. Should we take into account the first version of the entity and
   ignore / warn / throw an exception on the followings
   OR should we always override the state with the last version of the
   entity encountered (and warn or throw and exception optionally)
2. Should this rule be the same when we are discussing cascading from a
   single call / cascade tree to em.merge(x)
   And when it comes from two subsequent calls to merge
   em.merge(y1); em.merge(y2);

Unsurprisingly the spec does not mention this case explicitly but the
merge semantic indicates that the state of the entity provided is merged
into the state of the persistence context.

So my preference would be to last version wins which makes all situations similar.
I understand that cascading of merge could lead to the merge of entities
no longer associated with the entity that ends up in the database but I
prefer the simplicity of the rule leading to odd behavior is corner
cases than something complex to explain.

If we end up supporting the following behavior

    y = em.merge(y1); //state if y1 copied in y
    y = em.merge(y2); //state of y2 ignored and y keeps y1 state

I would be concerned it leads to a lot of misunderstanding and complains
from the users. And to me it would be against the spec as I read it.

Fundamentally merge is broken-ish and I tend to prefer the saveOrUpdate
moder which clearly throw an exception in case of conflicts like this.
But that's not the model that was chosen in JPA.

Emmanuel

On Tue 2014-04-08  2:50, Gail Badner wrote:
> After fixing HHH-6848, Hibernate throws IllegalStateException when merging entity 'x' if it has references to 2 detached entities 'y1' and 'y2' obtained from different sessions, and y1 and y2 represent the same persistent entity. In other words, y1 != y2.
> 
> I've pushed some FailureExpected test cases to org.hibernate.test.ops.MergeTest that illustrate this. [1]
> 
> Before fixing HHH-6848, one of the representations would be merged and the other would be ignored (probably overwritten). 
> 
> I'm looking into a fix that will restore this functionality as well as provide logging for this situation. I'll discuss logging in a separate email.
> 
> Merging multiple representations that have equivalent state would be straightforward. Things are more complicated when the representations do not have equivalent state. I'd like to discuss and get feedback before fixing this.
> 
> I am a little leery about allowing multiple representations that are not equivalent to be merged because data could be lost. I would prefer to throw an exception by default, and then provide a flag to override this behavior as suggested in HHH-8570. I discussed briefly with Steve E., and he preferred to address this concern by logging a warning. Opinions?
> 
> In any case, here are 2 possible strategies:
> 
> 1) The last one copied will "win". First, the state from one will be copied onto a pre-existing managed entity or a new managed copy, then later when the merge operation is cascaded to the other representation, a copy of its state will overwrite the managed entity state.
> 
> 2) The first representation detected will "win". The idea here is that y1 and y2 are both representations of the same entity; only 1 can be merged. When the first is detected, the merge operation is cascaded to its associations with cascade=MERGE or cascade=AL, then its state will be copied onto a pre-existing managed entity or a new managed copy. When a later representation is detected, it's state is not copied and the merge operation is not cascaded to its associations with cascade=MERGE or cascade=ALL.
> 
> I think 2) fits in better With the way merge currently works.
> 
> A problem with 1) is that we won't know when we are processing the last representation until all cascade-merges are finished. By then, the session may contain entities from cascading the merge operation from the earlier representations. This could result in persisting transient entities or updating entites that are only  associated with earlier representations.
> 
> With 2) we always know when we are processing the first representation and can more easily skip cascading the merge operation for representations detected later.
> 
> Comments?
> 
> Thanks,
> Gail
> 
> [1] https://github.com/hibernate/hibernate-orm/blob/0118376f8efd9b35d8be815c892f3ac7f9b6048f/hibernate-core/src/test/java/org/hibernate/test/ops/MergeTest.java#L829
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From steve at hibernate.org  Wed Apr  9 08:37:40 2014
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 9 Apr 2014 07:37:40 -0500
Subject: [hibernate-dev] Jira / GitHub issues
Message-ID: <CAFdSV9vTeQ0ra0hRQ=HDL1zmOpttQ4+jZkWr0_evh_1O4Xs-3g@mail.gmail.com>

Just a heads up that as or tomorrow (April 10) we should see the Jira /
GitHub issues resolved.  The last 2 issues we have been waiting on were
just resolved:

1) https://jira.atlassian.com/browse/DCON-391
2) https://jira.atlassian.com/browse/DCON-393

Essentially this most recent problem has been the synchronization process.
 Those 2 issues addressed different parts of that.

All-in-all, that should mean:

* Commit info should start synchronizing automatically again
* We should start to see Pull Requests automatically linked to the Jira
issue provided the Pull Request refers to the Jira issue key in its title.

From steve at hibernate.org  Wed Apr  9 08:38:18 2014
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 9 Apr 2014 07:38:18 -0500
Subject: [hibernate-dev] Ology, a social network running on Hibernate
In-Reply-To: <588C2812-CEC8-443F-B938-7AA1FC81E0BF@hibernate.org>
References: <CAGvEgx6wog+ShHxSzjO2ME0fJiNiVFJdVZPffqcPEwjEL-dpjw@mail.gmail.com>
	<588C2812-CEC8-443F-B938-7AA1FC81E0BF@hibernate.org>
Message-ID: <CAFdSV9tX0+nmNbMq=yhhkdOdE1FcYky5GDp=SF-yd3GzNzx+tQ@mail.gmail.com>

Looks nice Marc


On Tue, Apr 8, 2014 at 7:52 AM, Emmanuel Bernard <emmanuel at hibernate.org>wrote:

> Sweet :)
>
> On 07 Apr 2014, at 19:03, Marc Schipperheyn <m.schipperheyn at gmail.com>
> wrote:
>
> > Hi all,
> >
> > On another note I just wanted to mention the new release of Ology,
> > www.ology.com.br.
> > It's a social network that can be seen as a mix between Facebook and
> > LinkedIn exclusively for physicians that runs on Spring, Hibernate,
> > Hibernate Search, YUI. Although this is not a technical topic, and I
> > certainly don't intend to spam, I thought it might interest some people
> to
> > see this kind of platform running on Hibernate.
> >
> > Cheers,
> > Marc
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Wed Apr  9 08:39:33 2014
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 9 Apr 2014 07:39:33 -0500
Subject: [hibernate-dev] Why Hibernate 4.2.x should receive more updates
In-Reply-To: <CAGvEgx6=qxFFsLyAXvDPKJ_6zn9MtFDNHSyTJ8uvv1qDGQVrSA@mail.gmail.com>
References: <CAGvEgx50NCVSOGLJxYiqfgPjs0OLbFCmvX=TSh+zxq5kq63oQA@mail.gmail.com>
	<CAFdSV9szSjNzc4f-fb1948zbxvx0=p_sOV2-mtNt4vNncVz_3g@mail.gmail.com>
	<CAGvEgx6=qxFFsLyAXvDPKJ_6zn9MtFDNHSyTJ8uvv1qDGQVrSA@mail.gmail.com>
Message-ID: <CAFdSV9tUPpdJMf7hZVbNVmxGO4ZCC5dmq1Yy0ziNR4gfyQU3LA@mail.gmail.com>

Yes, I agree it is a shame.

BTW, did you see we just released yet another 4.2? ;)


On Mon, Apr 7, 2014 at 11:58 AM, Marc Schipperheyn <m.schipperheyn at gmail.com
> wrote:

> Fair enough. It's a shame though. Like it or not, there are tons of people
> using Spring and I'm guessing the vast majority will not be on 4.0 any time
> soon, even though they might want to. So, this will certainly impact the
> uptake of Hibernate latest version (including the amount of bug reports
> against the newer version you will receive which will indirectly impact
> quality etc). I was suggesting that it might make "business sense" to keep
> the support but I totally understand the need to optimize the use of
> resources.
>

From sanne at hibernate.org  Wed Apr  9 10:46:17 2014
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 9 Apr 2014 15:46:17 +0100
Subject: [hibernate-dev] Jira / GitHub issues
In-Reply-To: <CAFdSV9vTeQ0ra0hRQ=HDL1zmOpttQ4+jZkWr0_evh_1O4Xs-3g@mail.gmail.com>
References: <CAFdSV9vTeQ0ra0hRQ=HDL1zmOpttQ4+jZkWr0_evh_1O4Xs-3g@mail.gmail.com>
Message-ID: <CAFm4XO0L95+NDFEGbWe+-p+mcxwV7OLGwVAwfwbCFpbGk+QW2g@mail.gmail.com>

Nice, thanks Steve.
Do I need to change something in project configuration to benefit from
the automatic linking?

On 9 April 2014 13:37, Steve Ebersole <steve at hibernate.org> wrote:
> Just a heads up that as or tomorrow (April 10) we should see the Jira /
> GitHub issues resolved.  The last 2 issues we have been waiting on were
> just resolved:
>
> 1) https://jira.atlassian.com/browse/DCON-391
> 2) https://jira.atlassian.com/browse/DCON-393
>
> Essentially this most recent problem has been the synchronization process.
>  Those 2 issues addressed different parts of that.
>
> All-in-all, that should mean:
>
> * Commit info should start synchronizing automatically again
> * We should start to see Pull Requests automatically linked to the Jira
> issue provided the Pull Request refers to the Jira issue key in its title.
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From steve at hibernate.org  Wed Apr  9 11:18:10 2014
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 9 Apr 2014 10:18:10 -0500
Subject: [hibernate-dev] Jira / GitHub issues
In-Reply-To: <CAFm4XO0L95+NDFEGbWe+-p+mcxwV7OLGwVAwfwbCFpbGk+QW2g@mail.gmail.com>
References: <CAFdSV9vTeQ0ra0hRQ=HDL1zmOpttQ4+jZkWr0_evh_1O4Xs-3g@mail.gmail.com>
	<CAFm4XO0L95+NDFEGbWe+-p+mcxwV7OLGwVAwfwbCFpbGk+QW2g@mail.gmail.com>
Message-ID: <CAFdSV9vzh8-axZt-kLR6p2sM28X3U9sfrLSBDk0bygMsz4reLg@mail.gmail.com>

No, it should happen automatically.  *Should* :)  This new round of DVCS
support has been far from smooth.  I blame it on Atlassian being in the
DVCS game now with Stash.  I don't think its hard to see that they focus
their DVCS testing there rather than GitHub.


On Wed, Apr 9, 2014 at 9:46 AM, Sanne Grinovero <sanne at hibernate.org> wrote:

> Nice, thanks Steve.
> Do I need to change something in project configuration to benefit from
> the automatic linking?
>
> On 9 April 2014 13:37, Steve Ebersole <steve at hibernate.org> wrote:
> > Just a heads up that as or tomorrow (April 10) we should see the Jira /
> > GitHub issues resolved.  The last 2 issues we have been waiting on were
> > just resolved:
> >
> > 1) https://jira.atlassian.com/browse/DCON-391
> > 2) https://jira.atlassian.com/browse/DCON-393
> >
> > Essentially this most recent problem has been the synchronization
> process.
> >  Those 2 issues addressed different parts of that.
> >
> > All-in-all, that should mean:
> >
> > * Commit info should start synchronizing automatically again
> > * We should start to see Pull Requests automatically linked to the Jira
> > issue provided the Pull Request refers to the Jira issue key in its
> title.
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Wed Apr  9 12:23:51 2014
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 9 Apr 2014 11:23:51 -0500
Subject: [hibernate-dev] Metamodel - Entity primary key mappings
In-Reply-To: <30141365.2803053.1396999940500.JavaMail.zimbra@redhat.com>
References: <CAFdSV9to5AxoMKQAsBqY0qW5Jbz2480TVQ-eeAMHPfnfBwHGQA@mail.gmail.com>
	<CAFdSV9u9Rs5wJCRD6-_X0JBBA=Fpeq7rJiUDsRswkuQkvW3L1w@mail.gmail.com>
	<30141365.2803053.1396999940500.JavaMail.zimbra@redhat.com>
Message-ID: <CAFdSV9uQSH9Whcxp8UsgFRYCJzSEG9qbHuq26PRr-938-Y6_cg@mail.gmail.com>

So we need to decide how to best represent the identifier for the entity.
 That's ultimately the disconnect here.  Hibernate historically had 3 ways
to represent ids:

* simple - these were explicitly basic type ids: longs, ints, strings, etc.
 == <hbm:id/>
* aggregated composite - essentially @EmbeddedId
* non-aggregated composite - like @IdClass cases, but without the @IdClass;
the entity itself was the identifier value.


Notice a few things:
1) A simple identifier could never be an association in legacy Hibernate.
 A "key-many-to-one" was ALWAYS wrapped in a composite, even if it was the
attribute on the composite.  Now Hibernate also has the concept of a 1-1
with a "foreign generator" which is essentially the same as the JPA feature
of `@Id @ManyToOne` or `@Id @OneToOne`.  Recently I made some significant
changes to "simple derived ids" such that they no longer get wrapped in a
virtual embedded composite.
2) For composite ids, JPA requires either a EmbeddedId or a IdClass.
 Legacy Hibernate does not, via its "embedded (virtual) identifier".  While
I think we should continue to support non-aggregated composite without an
IdClass, I do think we should warn users when they do this.  So at the
moment we really have the following ways to represent an id:

* simple basic id
* simple derived id ( @Id + @OneToOne or @ManyToOne )
* aggregated composite
* non-aggregated composite
* non-aggregated composite + IdClass

3) JPA allows EmbeddedId to have (singular) associations. IdClass cannot;
in cases where IdClass maps one or more associations.. well the convoluted
rules in "derived identities" section kick in.  But the important take away
is that the structure of the 2 id representations is very different.  For
example:


@Entity
class Customer {
  @Id Integer id;
  ...
}

class OrderIdClass implements Serializable {
    Integer customer;
    int orderNumber;
}

@Entity
@IdClass(OrderIdClass.class)
class Order implements Serializable {
  @Id @ManyToOne ...
  Customer customer;
  @Id
  int orderNumber;
  ...
}

Looking at Order, the internal representation of its identity (used to
cache it within the Session ,etc) is the Order itself - Hibernate's legacy
"embedded identifier" which includes the many-to-one.  The representation
used in lookups is OrderIdClass which does not contain the many-to-one.

Note that EmbeddedId can follow the same paradigm according to JPA, which
is another use-case of MapsId:


@Embeddable
class OrderId implements Serializable {
    Integer customer;
    int orderNumber;
}

@Entity
class Order implements Serializable {
  @EmbeddedId
  OrderId id;

  @MapsId
  @ManyToOne ...
  Customer customer;
  ...
}

Ugh.



On Tue, Apr 8, 2014 at 6:32 PM, Gail Badner <gbadner at redhat.com> wrote:

> Hi Steve,
>
> Problem happens when a @ManyToOne is assocated with an entity that has an
> @IdClass.
>
> I looked for a core test that reproduces the problem, but it looks like
> the core tests using @IdClass that fail for a different reason before this
> problem shows up.
>
> The following envers tests reproduce the problem:
>
>
> org.hibernate.envers.test.integration.onetoone.bidirectional.ids.MulIdBidirectional
>
> org.hibernate.envers.test.integration.onetomany.detached.BasicDetachedSetWithMulId
> org.hibernate.envers.test.integration.onetomany.BasicSetWithMulId
> org.hibernate.envers.test.integration.query.ids.MulIdOneToManyQuery
>
> When binding the JdbcDataType for the ID:
>
> EntityType.getIdentifierOrUniqueKeyType( metadataCollector() ) is called,
> which ends up calling:
>
> InFlightMetadataCollectorImpl.getIdentifierType( associatedEntityName )
> which returns
>
>
> entityBinding.getHierarchyDetails().getEntityIdentifier().getAttributeBinding()
>                                         .getHibernateTypeDescriptor()
>                                         .getResolvedTypeMapping();
>
> which returns an EmbeddedComponentType; its PojoComponentTuplizer is
> expecting to get/set values in the entity object.
>
> InFlightMetadataCollectorImpl.getIdentifierType( associatedEntityName )
> should be returning the ComponentType for the @IdClass. Problem is the
> ComponentType for the @IdClass is not built until the persisters are being
> built and PropertyFactory.buildIdentifierProperty() is called. This is
> because I didn't think it was needed until then. Now I see that it is
> needed when binding the JdbcDataType.
>
> The test ultimately fails due to PropertyAccessException when trying to
> insert the many-to-one. This is because the ID value for the associated
> entity is gotten from the EntityEntry and it is an instance of the @IdClass
> class, while the PojoComponentTuplizer for the ID is expecting an entity
> instance.
>
> Gail
>
> ----- Original Message -----
> > From: "Steve Ebersole" <steve at hibernate.org>
> > To: "hibernate-dev" <hibernate-dev at lists.jboss.org>
> > Sent: Monday, April 7, 2014 4:45:18 PM
> > Subject: Re: [hibernate-dev] Metamodel - Entity primary key mappings
> >
> > What I am thinking at the moment is to change up
> > org.hibernate.metamodel.spi.binding.EntityIdentifier to look like:
> >
> > public class EntityIdentifier {
> >   private final EntityBinding entityBinding;
> >
> >   private EntityIdentifierNature nature;
> >   private IdentifierAttributeBindings attributeBindings;
> >   private IdClassBinding idClassBinding;
> >   private Map<String,String> derivedIdMap;
> >   private IdentifierGenerator generator;
> > }
> >
> >
> > 1) IdentifierAttributeBindings would play sort of the same role
> > as
> >
> org.hibernate.metamodel.spi.binding.EntityIdentifier.EntityIdentifierBinding.
> >  Essentially it would hold the binding state for each of the identifier
> > attributes (those marked with @Id or @EmbeddedId).  Still not sure the
> best
> > external representation of this.  Exposing a simple
> > List<SingularAttributeBinding> for all identifier natures versus
> > specialized IdentifierAttributeBindings for each nature are running a
> > neck-and-neck race atm.  Thoughts?  Votes?
> >
> > 2) IdClassBinding would be a
> > specialized
> org.hibernate.metamodel.spi.binding.EmbeddableBindingContributor
> > for describing the @IdClass mapping
> >
> > 3) `derivedIdMap` holds the various @MapsId mappings for the entity.  I
> was
> > tempted to move this off to IdClassBinding except that @MapsId also
> refers
> > to @EmbeddedId attributes.
> >
> > Thoughts?  Worries?  Concerns?
> >
> >
> >
> >
> > On Mon, Apr 7, 2014 at 10:27 AM, Steve Ebersole <steve at hibernate.org>
> wrote:
> >
> > > I've been spending a lot of time the last 2 weeks trying to get a good
> > > "mental model" as to how to best model the information pertaining to an
> > > entity's primary key.  Most of this effort went into trying to
> understand
> > > JPA's "derived identity" support.
> > >
> > > First and foremost I want to get away from modelling this (in the
> > > metamodel) as a singular attribute. This is unnatural in the
> > > "non-aggregated composite id" case forcing us to build a "virtual"
> > > attribute.  I think that this is very doable with the distinction I
> > > recently added to the metamodel between Embedded/Embeddable.
> > >
> > > Next is to finish up support for IdClass, which should be close to
> done.
> > >  Gail, I know you had mentioned a case where that support was lacking.
> > >  Could you send me the specifics so I make sure we get that case
> covered?
> > >
> > > Beyond that is mainly incorporating support for JPA "derived
> identities".
> > >  With that, I want to share some of my understanding and see if I
> missed
> > > anything...
> > >
> > > "Derived identity" support is essentially Hibernate's much older
> "foreign"
> > > identifier generator, namely that the child entity gets (all of or
> part of)
> > > its identifier from a to-one association defined on it, from its
> "foreign
> > > key" value.  But of course the spec verbosely covers all the ways this
> > > might happen.
> > >
> > > The very first thing I noticed is that the examples in the spec come
> in 2
> > > distinct top-level flavors.  Examples 1-3 are cases where the "parent
> id"
> > > is simply part of the "derived (child) id".  Examples 4-6 are cases
> where
> > > the parent id *is* the child id (shared pk).  I am not sure how
> important
> > > this distinction is in practice, but I also noticed that @MapsId is
> only
> > > pertinent wrt the second set of cases where we have the shared pk.
>  This
> > > was the first time I have noticed that distinction.
> > >
> > > The one monkey wrench that JPA throws into the works here is that there
> > > are essentially multiple views of an entity's PK.  As one example,
> take the
> > > spec's "Example 4.a":
> > >
> > > @Entity
> > > public class Person {
> > >   @Id String ssn;
> > >   ...
> > > }
> > >
> > > @Entity
> > > public class MedicalHistory {
> > >   @Id
> > >   @OneToOne
> > >   @JoinColumn(name="FK")
> > >   Person patient;
> > >   ...
> > > }
> > >
> > > Ultimately, the primary key of MedicalHistory is the `ssn` of its
> > > associated Person.  Thus both of these are valid:
> > >
> > > entityManager.find( MedicalHistory.class, somePerson );
> > > entityManager.find( MedicalHistory.class, somePerson.ssn );
> > >
> > > For those who have seen it, this is the reason for the wonkiness inside
> > > Hibernate's runtime engine wrt incoming id type while doing a load.
> > >
> > >
> > > I am still going through all the use cases (ours plus JPA) to make
> sure we
> > > get everything covered.  But I wanted to hopefully get some discussion
> > > started around this and get any thoughts y'all might have.
> > >
> > >
> > >
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
>

From emmanuel at hibernate.org  Wed Apr  9 15:01:22 2014
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Wed, 9 Apr 2014 21:01:22 +0200
Subject: [hibernate-dev] Java 8, type annotations and Hibernate Validator
Message-ID: <20140409190122.GC5788@hibernate.org>

I always thought that type annotations would allow us to look via
refection to annotations like

    public class Foo {
       public Set< @NotNull String> names;
    }

But looking at some tutorials like
http://jaxenter.com/jsr-308-explained-java-type-annotations-49929.html

it seems that these annotations are only "visible" to a compiler plug-in
/ processor.

Am I right?

If that turns out true that would suck as it would only be useful to
static tools. I wish I had checked the spec earlier to influence it :(

Emmanuel

From gunnar at hibernate.org  Wed Apr  9 15:19:26 2014
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 9 Apr 2014 21:19:26 +0200
Subject: [hibernate-dev] Java 8, type annotations and Hibernate Validator
In-Reply-To: <20140409190122.GC5788@hibernate.org>
References: <20140409190122.GC5788@hibernate.org>
Message-ID: <CADGJaX_kAHhu_LSdK+kYqS9Ci2adZMJ+mGohSgAwe9VnWby2pA@mail.gmail.com>

2014-04-09 21:01 GMT+02:00 Emmanuel Bernard <emmanuel at hibernate.org>:

> I always thought that type annotations would allow us to look via
> refection to annotations like
>
>     public class Foo {
>        public Set< @NotNull String> names;
>     }
>
> But looking at some tutorials like
> http://jaxenter.com/jsr-308-explained-java-type-annotations-49929.html
>
> it seems that these annotations are only "visible" to a compiler plug-in
> / processor.
>
> Am I right?
>

No, one can access type annotations at runtime (at least for fields, method
signatures and so on) via reflection. A while ago I feared the same, so I
asked on core-libs-dev [1] and got confirmation that it's possible. That's
how you'd do it:

    // given
    private List<@NotNull String> names;

    Field namesField = ...;

    // List<String>
    AnnotatedParameterizedType type = (AnnotatedParameterizedType)
namesField.getAnnotatedType();

    // String
    AnnotatedType typeArg = type.getAnnotatedActualTypeArguments()[0];

    // @NotNull
    Annotation annotation = typeArg.getAnnotations()[0];

It's one of the planned tasks of the HV GSoC project to make use of this to
support constraints as in your example.

If that turns out true that would suck as it would only be useful to
> static tools. I wish I had checked the spec earlier to influence it :(
>
> Emmanuel
>

--Gunnar

[1]
http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-March/025732.html


> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From emmanuel at hibernate.org  Wed Apr  9 15:34:21 2014
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Wed, 9 Apr 2014 21:34:21 +0200
Subject: [hibernate-dev] Java 8, type annotations and Hibernate Validator
In-Reply-To: <CADGJaX_kAHhu_LSdK+kYqS9Ci2adZMJ+mGohSgAwe9VnWby2pA@mail.gmail.com>
References: <20140409190122.GC5788@hibernate.org>
	<CADGJaX_kAHhu_LSdK+kYqS9Ci2adZMJ+mGohSgAwe9VnWby2pA@mail.gmail.com>
Message-ID: <DB95174A-6742-4DBC-A862-14EBC14C1768@hibernate.org>

Cool, I?ll be able to sleep tonight :)

On 09 Apr 2014, at 21:19, Gunnar Morling <gunnar at hibernate.org> wrote:

> 2014-04-09 21:01 GMT+02:00 Emmanuel Bernard <emmanuel at hibernate.org>:
> I always thought that type annotations would allow us to look via
> refection to annotations like
> 
>     public class Foo {
>        public Set< @NotNull String> names;
>     }
> 
> But looking at some tutorials like
> http://jaxenter.com/jsr-308-explained-java-type-annotations-49929.html
> 
> it seems that these annotations are only "visible" to a compiler plug-in
> / processor.
> 
> Am I right?
> 
> No, one can access type annotations at runtime (at least for fields, method signatures and so on) via reflection. A while ago I feared the same, so I asked on core-libs-dev [1] and got confirmation that it's possible. That's how you'd do it:
> 
>     // given    
>     private List<@NotNull String> names;
>     Field namesField = ...;
> 
>     // List<String>
>     AnnotatedParameterizedType type = (AnnotatedParameterizedType) namesField.getAnnotatedType();
> 
>     // String
>     AnnotatedType typeArg = type.getAnnotatedActualTypeArguments()[0];
> 
>     // @NotNull
>     Annotation annotation = typeArg.getAnnotations()[0];
> 
> It's one of the planned tasks of the HV GSoC project to make use of this to support constraints as in your example.
> 
> If that turns out true that would suck as it would only be useful to
> static tools. I wish I had checked the spec earlier to influence it :(
> 
> Emmanuel
> 
> --Gunnar 
> 
> [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-March/025732.html
>  
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> 


From gbadner at redhat.com  Wed Apr  9 18:24:06 2014
From: gbadner at redhat.com (Gail Badner)
Date: Wed, 9 Apr 2014 18:24:06 -0400 (EDT)
Subject: [hibernate-dev] 5.0 metamodel binding
In-Reply-To: <22DD4F7E-7BAB-41F9-9C64-F5A658FE0D3E@hibernate.org>
References: <CAFdSV9tdD=47o0xf2BnTcaXEd=1HTEcyF=RP6wGLVKhMwNoR9w@mail.gmail.com>
	<22DD4F7E-7BAB-41F9-9C64-F5A658FE0D3E@hibernate.org>
Message-ID: <1179022439.3853790.1397082246356.JavaMail.zimbra@redhat.com>

Envers looks at @MappedSuperclass ClassInfo to see if it has any attributes that are audited. If it finds one, then Envers has to find the corresponding AttributeBinding in the EntityBinding to get it's access type, column names, etc. 

I don't think it really requires a MappedSuperclassBinding, but tweaking the domain model would help.

I think adding a method like this will provide enough information:

    javax.persistence.metamodel.Attribute.getDeclaringType() returning ManagedType<X>

Currently domain model has:

    org.hibernate.metamodel.spi.domain.Attribute.getAttributeContainer() returning AttributeContainer

I think adding the following would work for Envers:

    org.hibernate.metamodel.spi.domain.Attribute.getDeclaringAttributeContainer() returning AttributeContainer

At least that's what I see so far...

----- Original Message -----
> From: "Hardy Ferentschik" <hardy at hibernate.org>
> To: "Steve Ebersole" <steve at hibernate.org>
> Cc: "Hibernate" <hibernate-dev at lists.jboss.org>
> Sent: Tuesday, February 18, 2014 3:34:31 AM
> Subject: Re: [hibernate-dev] 5.0 metamodel binding
> 
> 
> On 18 Jan 2014, at 04:28, Steve Ebersole <steve at hibernate.org> wrote:
> 
> > At the moment all of metamodel binding completely mis-handles
> > MappedSuperclasses.  The annotation source processor handles them somewhat,
> > but in a very unusable way; it basically flattens all MappedSuperclass info
> > into the nearest Entity.  This is because the source package does not at
> > all support the definition of MappedSuperclass.  And then of course
> > bindings do nothing with it, since it is not accounted for in source.
> > 
> > To add this support I plan on the following changes:
> > 
> > 1) Move lots of the information currently defined by RootEntitySource into
> > EntityHierarchy.  The identifier, version, etc is actually a function of
> > the hierarchy as a whole, so conceptually it makes more sense there anyway.
> > And that mirrors the way we modeled it in the binding spi.
> > 2) Generalize the EntityHierarchy tree to allow mixing Entity and
> > MappedSuperclass sources.  A MappedSuperclass source actually needs to be
> > defined.
> > 3) Model MappedSuperclass in the binding spi as well.
> 
> +1 especially for #3. The reason the annotations side did this flattening was
> as you say
> the fact that there was no source equivalent. I think we might have discussed
> this briefly
> once, but affair back then we decided there was no special need to reflecting
> mapped
> super class in the source level.
> 
> ?Hardy
> 
> 
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> 


From sanne at hibernate.org  Wed Apr  9 18:31:19 2014
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 9 Apr 2014 23:31:19 +0100
Subject: [hibernate-dev] Ology, a social network running on Hibernate
In-Reply-To: <CAFdSV9tX0+nmNbMq=yhhkdOdE1FcYky5GDp=SF-yd3GzNzx+tQ@mail.gmail.com>
References: <CAGvEgx6wog+ShHxSzjO2ME0fJiNiVFJdVZPffqcPEwjEL-dpjw@mail.gmail.com>
	<588C2812-CEC8-443F-B938-7AA1FC81E0BF@hibernate.org>
	<CAFdSV9tX0+nmNbMq=yhhkdOdE1FcYky5GDp=SF-yd3GzNzx+tQ@mail.gmail.com>
Message-ID: <CAFm4XO0BB4_E4+ss6ruArxXHWF8Z118eYuHbcXrQk=7ut500tQ@mail.gmail.com>

Indeed!
Thanks for sharing, always nice to see such achievements.

Sanne

On 9 April 2014 13:38, Steve Ebersole <steve at hibernate.org> wrote:
> Looks nice Marc
>
>
> On Tue, Apr 8, 2014 at 7:52 AM, Emmanuel Bernard <emmanuel at hibernate.org>wrote:
>
>> Sweet :)
>>
>> On 07 Apr 2014, at 19:03, Marc Schipperheyn <m.schipperheyn at gmail.com>
>> wrote:
>>
>> > Hi all,
>> >
>> > On another note I just wanted to mention the new release of Ology,
>> > www.ology.com.br.
>> > It's a social network that can be seen as a mix between Facebook and
>> > LinkedIn exclusively for physicians that runs on Spring, Hibernate,
>> > Hibernate Search, YUI. Although this is not a technical topic, and I
>> > certainly don't intend to spam, I thought it might interest some people
>> to
>> > see this kind of platform running on Hibernate.
>> >
>> > Cheers,
>> > Marc
>> > _______________________________________________
>> > hibernate-dev mailing list
>> > hibernate-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From galder at redhat.com  Fri Apr 11 09:25:04 2014
From: galder at redhat.com (=?windows-1252?Q?Galder_Zamarre=F1o?=)
Date: Fri, 11 Apr 2014 15:25:04 +0200
Subject: [hibernate-dev] On 2nd level cache and requirements off the
	cache implementor
In-Reply-To: <CAFm4XO2QKBk_M_=pc54StDC-urhopzWKmJmQxTN7WRAYoFa0OA@mail.gmail.com>
References: <20140404132756.GR942@hibernate.org>
	<CAFm4XO2QKBk_M_=pc54StDC-urhopzWKmJmQxTN7WRAYoFa0OA@mail.gmail.com>
Message-ID: <FBD5AF41-274D-44EA-85F9-5CC1EE697D99@redhat.com>

The reason Infinispan currently uses transactions and forces JTA transactions, for any clustering mode that requires entity updates, is because the need to rollback contents if they?re partially applied in the cluster. Without transactions, we do not have the capabilities to rollback changes if only half of the nodes apply the update.

On 04 Apr 2014, at 20:13, Sanne Grinovero <sanne at hibernate.org> wrote:

> Both Ehcache and Infinispan support transactions, but Ehcache doesn't
> use this capability when running as Hibernate 2nd level cache, while
> Infinispan uses it more as an implementation detail to provide
> internal consistency, and not to participate with the application
> transaction.

^ Not sure what transactions you area talking about there, whether Hibernate or JTA transactions, but Infinispan does participate in the on-going JTA transaction that the application is running, when the mode is transactional. It interacts with the transaction manager via synchronizations.

> 
> So I think that the fact they both happen to also support Transactions
> should be considered incidental.
> 
> I'd very interested too to hear from Galder and Alex about the
> required atomic operation they build on. I could look at the code but
> I'm primarily wondering of what they'd rather need conceptually, than
> knowing what they are forced to do today.
> 
> Sanne
> 
> On 4 April 2014 14:27, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
>> This is brain storming at this stage.
>> 
>> How much is required of a cache provider as far as semantic is
>> concerned and be cluster safe? The only providers we currently offer are EhCache and
>> Infinispan
>> http://docs.jboss.org/hibernate/orm/4.3/manual/en-US/html_single/#performance-cache
>> 
>> But both happen to be transactional so I wonder if that's a requirement
>> and if not what are the list of atomic operations that a clustered cache
>> provider would need to offer.
>> 
>> Any hint and feedback appreciated :)
>> 
>> Emmanuel
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev


--
Galder Zamarre?o
galder at redhat.com
twitter.com/galderz



From sanne at hibernate.org  Fri Apr 11 10:43:49 2014
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 11 Apr 2014 15:43:49 +0100
Subject: [hibernate-dev] [Search] Double maintenance release 4.4.3.Final and
	4.5.1.Final
Message-ID: <CAFm4XO1Z1bX7cpDo3O2y+h3B6jF21e8y1z+qas=bgAro5f5ixQ@mail.gmail.com>

Hi all,
we just released updates for both of the most recent stable branches
of Hibernate Search:

http://in.relation.to/Bloggers/MaintenanceReleasesForStableBranchesOfHibernateSearch

-- Sanne

From steve at hibernate.org  Sat Apr 12 12:56:34 2014
From: steve at hibernate.org (Steve Ebersole)
Date: Sat, 12 Apr 2014 11:56:34 -0500
Subject: [hibernate-dev] Some thoughts on possible Binder changes
Message-ID: <CAFdSV9ugvYJjrfbviMy80Wf6Lze82C27DcXBg8-hBcGD+O7xGg@mail.gmail.com>

The Background

Binder deals with dependencies between things.  An Entity cannot be fully
bound until its attributes and identifier are fully bound.  An Embeddable
cannot be fully bound until its sub-attributes are fully bound.  One Entity
might depend on another by nature of a "key many to one" or a "one to one"
or a "mappedBy" or...  In short, there is a lot of dependency to the order
things must be bound.

Some of these dependencies are *a priori* in nature.  Basic attributes
should be bound before embedded and associations.  Attributes for a
Entity/Embeddable need to be fully bound before the Entity/Embeddable can
be considered complete.  The Binder tries to handle these *a priori
*dependencies
simply by the order in which it processes things internally.  This works
reasonably well.

The other dependencies are *a posteriori *in nature, in that we cannot
fully understand them in terms of ordering until we get into the processing
of the data.  This includes "key many to one" or a "one to one" or a
"mappedBy" examples from above.

Turns out that binding of Entity and Embeddable are both functionally *a
posteriori* as well because of the fact that we first create those bindings
(as a shell if you will) and add the bindings for their attributes, etc
after the fact.  So we can't understand that either are fully resolved
until after the fact.  Not a huge deal, just pointing it out.


The Use Case

I have been working on completing identifier handling, especially in the
case of composite ids.  As more "background" to where my thoughts came
from, let me walk y'all through how Binder currently deals with this stuff.
 As I mentioned above, as part of its *a posteriori* handling, Binder
attempts to cycle through attributes based on their nature:

   1. Process composites
   2. Process simple/basic attributes
   3. Process many-to-one
   4. Process one-to-one
   5. Process many-to-one (mappedBy)
   6. Process one-to-one (mappedBy)
   7. Process plural attributes
   8. Process plural attributes (mappedBy)

In terms of dealing with composite ids, step (1) really just means creating
the Embeddable "shells" (the EmbeddableBinding instance).  But at this
point the EmbeddableBinding is not done, we still need its attributes
"resolved" or "bound".  To accomplish this, as Binder walks through the
rest of the steps, it continually checks whether the completion of the
attribute it just bound completes the binding of the Embeddable.  So as it
is looping over every attribute, for each attribute it loops over every
known incomplete EmbeddableBinding and checks whether that attribute
"completes" the EmbeddableBinding and if so finalizes it's binding.

First thing I noticed is that that is a lot of looping (within looping).
 While I am sure that has some performance impact, that is not really my
concern.  My concern was more the non-definitive state of things being
resolved.  Coming back to the EmbeddableBinding as a composite id... quite
a few of those steps rely on the id of an entity being fully resolved.


Events

Which got me to thinking about using events to signal the completion of
things, and the ability to listen for these events.  Don't worry, I mean
events here as fairly light weight concept :)

Essentially the idea is to have producers and listeners and to have Binder
act as the bus.  So let me apply this to the composite id case above as an
example.  So we'd still have an initial step that creates the
EmbeddableBinding instances.  It would use a EmbeddableBindingCreator
delegate (I was already in the process of breaking up the 4K line Binder
class to use some delegation) to do the EmbeddableBinding creation.
 EmbeddableBindingCreator would also implement the "listener" contract for
AttributeBinding completion; as attributes are completed, if they are part
of an EmbeddableBinding we "check them off" and when an EmbeddableBinding
has no more unresolved sub-attributes we would finalize the
EmbeddableBinding.  Here, EmbeddableBindingCreator would also play a
"producer" role; when the EmbeddableBinding is finalized, it would notify
the bus of that.  And then registered listeners for that event could react.

Consider a nested composite (Embedded w/in an Embeddable):

@Entity
class Person {
  ...
  @Embedded Address address;
}

@Embeddable
class Address {
  ...
  @Embedded Zip zip;
}

@Embeddable
class Zip {
  ..
  String code;
  String plus4;
}

The initial step has EmbeddableBindingCreator create the
EmbeddableBinding(Person#address)
and the EmbeddableBinding(Person#address#zip).  Additionally,
EmbeddableBindingCreator registers the sub-attribute roles making up each
EmbeddableBinding and keeps track of them (the "unresolved ones").

The second step processes basic attributes (note to self, ideally we should
make sure the nested simple attributes are ordered first here):
1) Say first we'd process Person#address#zip#code; we finalize it and fire
off the "attribute bound" event which EmbeddableBindingCreator gets
notified of.  EmbeddableBindingCreator removes the Person#address#zip#code
attribute role from the unresolved attributes for
EmbeddableBinding(Person#address#zip).  However, we see there is still more
unresolved sub-attributes, so nothing more to do.
2) Then we process Person#address#zip#plus4, finalize it and fire off the
"attribute bound" event which EmbeddableBindingCreator gets notified of.
 EmbeddableBindingCreator removes the Person#address#zip#plus4 attribute
role from the unresolved attributes for
EmbeddableBinding(Person#address#zip).  Now it sees that all of the
sub-attributes for EmbeddableBinding(Person#address#zip) are resolved, and
so finalizes EmbeddableBinding(Person#address#zip), firing off its own
event that the embeddable was finalized.

That event routes back to Binder, which directs it back to a listener for
the Person#address attribute (which was registered as waiting on the
EmbeddableBinding(Person#address#zip) as one of its attribute types).  We
finalize that attribute, and fire its completion event which again
EmbeddableBindingCreator gets notified of... And so on

FYI, the finalization aspect is important because it signals when we are
able to resolve the Hibernate Type for things that refer to these.


Concerns

There are some concerns with such an approach.  Here are the ones I had.
 Maybe y'all have others?

First, there is the general pros/cons of sequential processing versus
event-driven processing.  Some folks view event-driven processing as more
convoluted, harder to follow.

Another concern is cases where a "bi-directional dependency" exists, which
might lead to an indefinite wait.  I do think adding some "finish" up step
at the end of the initial 1-8 steps is important where each
listener/producer is able to report things it is still waiting on.


Anyway... thoughts? comments?

From hardy at hibernate.org  Sat Apr 12 14:15:29 2014
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Sat, 12 Apr 2014 20:15:29 +0200
Subject: [hibernate-dev] Some thoughts on possible Binder changes
In-Reply-To: <CAFdSV9ugvYJjrfbviMy80Wf6Lze82C27DcXBg8-hBcGD+O7xGg@mail.gmail.com>
References: <CAFdSV9ugvYJjrfbviMy80Wf6Lze82C27DcXBg8-hBcGD+O7xGg@mail.gmail.com>
Message-ID: <8533C68B-4323-4A9C-828F-C581C56079B4@hibernate.org>


On 12 Jan 2014, at 18:56, Steve Ebersole <steve at hibernate.org> wrote:

> The Background

?

Thanks Steve, for this really nice summary. It is always good to share some basic design/implementation
details.

> In terms of dealing with composite ids, step (1) really just means creating
> the Embeddable "shells" (the EmbeddableBinding instance).  But at this
> point the EmbeddableBinding is not done, we still need its attributes
> "resolved" or "bound".  To accomplish this, as Binder walks through the
> rest of the steps, it continually checks whether the completion of the
> attribute it just bound completes the binding of the Embeddable.  So as it
> is looping over every attribute, for each attribute it loops over every
> known incomplete EmbeddableBinding and checks whether that attribute
> "completes" the EmbeddableBinding and if so finalizes it's binding.

What do you mean by ?completes?. How do you know that the EmbeddableBinding is complete.


> Which got me to thinking about using events to signal the completion of
> things, and the ability to listen for these events.  Don't worry, I mean
> events here as fairly light weight concept :)

For what it?s worth, Strong had once the same idea. Instead of rechecking and looping he also wanted to
introduce some sort of event based processing. I thought the idea sounded promising.
I am not sure how far he got or whether he even started. I think this was not long before metamodel was put on
ice fore a while.

> Essentially the idea is to have producers and listeners and to have Binder
> act as the bus.  So let me apply this to the composite id case above as an
> example.  So we'd still have an initial step that creates the
> EmbeddableBinding instances.  It would use a EmbeddableBindingCreator
> delegate (I was already in the process of breaking up the 4K line Binder
> class to use some delegation)

+1 to anything which can break up the Binder. 


> Consider a nested composite (Embedded w/in an Embeddable):
> 
> @Entity
> class Person {
>  ...
>  @Embedded Address address;
> }
> 
> @Embeddable
> class Address {
>  ...
>  @Embedded Zip zip;
> }
> 
> @Embeddable
> class Zip {
>  ..
>  String code;
>  String plus4;
> }
> 
> The initial step has EmbeddableBindingCreator create the
> EmbeddableBinding(Person#address)
> and the EmbeddableBinding(Person#address#zip).  Additionally,
> EmbeddableBindingCreator registers the sub-attribute roles making up each
> EmbeddableBinding and keeps track of them (the "unresolved ones").
> 
> The second step processes basic attributes (note to self, ideally we should
> make sure the nested simple attributes are ordered first here):
> 1) Say first we'd process Person#address#zip#code; we finalize it and fire
> off the "attribute bound" event which EmbeddableBindingCreator gets
> notified of.  EmbeddableBindingCreator removes the Person#address#zip#code
> attribute role from the unresolved attributes for
> EmbeddableBinding(Person#address#zip).  However, we see there is still more
> unresolved sub-attributes, so nothing more to do.
> 2) Then we process Person#address#zip#plus4, finalize it and fire off the
> "attribute bound" event which EmbeddableBindingCreator gets notified of.
> EmbeddableBindingCreator removes the Person#address#zip#plus4 attribute
> role from the unresolved attributes for
> EmbeddableBinding(Person#address#zip).  Now it sees that all of the
> sub-attributes for EmbeddableBinding(Person#address#zip) are resolved, and
> so finalizes EmbeddableBinding(Person#address#zip), firing off its own
> event that the embeddable was finalized.
> 
> That event routes back to Binder, which directs it back to a listener for
> the Person#address attribute (which was registered as waiting on the
> EmbeddableBinding(Person#address#zip) as one of its attribute types).  We
> finalize that attribute, and fire its completion event which again
> EmbeddableBindingCreator gets notified of... And so on

Sounds reasonable. As always the devil is probably in the detail. I don?t know enough about 
the corner cases and complications to point out where this approach would cause problems. 

> First, there is the general pros/cons of sequential processing versus
> event-driven processing.  Some folks view event-driven processing as more
> convoluted, harder to follow.

It can not get much worse than following the 4k Binder as it stands now. Event based processing 
can sometimes be tricky. Maybe it would help in this case to document the approach and 
algorithm and the main actors. Either in the javadocs or maybe even better in an topical guide (more
dev centric in this case).

> Anyway... thoughts? comments?

For me it is also a question of time and resources. I agree that cleaning up the binding code would be 
awesome, but on the other hand I thought most of the details for binding the new metamodel had been
sorted out by now. Is it worth rewriting now. On the other hand, if there are real issues with the code
it might be worth the try.


?Hardy



From steve at hibernate.org  Sat Apr 12 14:55:28 2014
From: steve at hibernate.org (Steve Ebersole)
Date: Sat, 12 Apr 2014 13:55:28 -0500
Subject: [hibernate-dev] Some thoughts on possible Binder changes
In-Reply-To: <8533C68B-4323-4A9C-828F-C581C56079B4@hibernate.org>
References: <CAFdSV9ugvYJjrfbviMy80Wf6Lze82C27DcXBg8-hBcGD+O7xGg@mail.gmail.com>
	<8533C68B-4323-4A9C-828F-C581C56079B4@hibernate.org>
Message-ID: <CAFdSV9uZAptq8bOT3GJnjU8hkBDsrr5qUFwCEpiq5GQHRNLj1g@mail.gmail.com>

Thanks for the response.  See inline...


On Sat, Apr 12, 2014 at 1:15 PM, Hardy Ferentschik <hardy at hibernate.org>wrote:

>
> On 12 Jan 2014, at 18:56, Steve Ebersole <steve at hibernate.org> wrote:
>
> > The Background
>
> ...
>
> Thanks Steve, for this really nice summary. It is always good to share
> some basic design/implementation
> details.
>
> > In terms of dealing with composite ids, step (1) really just means
> creating
> > the Embeddable "shells" (the EmbeddableBinding instance).  But at this
> > point the EmbeddableBinding is not done, we still need its attributes
> > "resolved" or "bound".  To accomplish this, as Binder walks through the
> > rest of the steps, it continually checks whether the completion of the
> > attribute it just bound completes the binding of the Embeddable.  So as
> it
> > is looping over every attribute, for each attribute it loops over every
> > known incomplete EmbeddableBinding and checks whether that attribute
> > "completes" the EmbeddableBinding and if so finalizes it's binding.
>
> What do you mean by "completes". How do you know that the
> EmbeddableBinding is complete.
>

For embeddables, this boils down to its sub-attributes being fully bound.
Ultimately we need to be able to generate the Hibernate Type.  So looking
at my example below, ultimately what we care about in regards to
Person#address is the resolved Type for that attribute.

So here, "completes" is the verb form; the idea being simply.. was the
attribute we just finished processing the last unresolved sub-attribute for
a embeddable; did it "complete" the embeddable in terms of all its
sub-attributes now being done.

As for how we know that, that depends.  In the existing Binder code we
literally iterate the attributes making up the embeddable and see if the
Type for all those sub-attributes has been resolved.
 See org.hibernate.metamodel.internal.binder.Binder#completeCompositeAttributeBindingIfPossible
for the current process.

I am suggesting this change to use events as outlined below.



>
> > Which got me to thinking about using events to signal the completion of
> > things, and the ability to listen for these events.  Don't worry, I mean
> > events here as fairly light weight concept :)
>
> For what it's worth, Strong had once the same idea. Instead of rechecking
> and looping he also wanted to
> introduce some sort of event based processing. I thought the idea sounded
> promising.
> I am not sure how far he got or whether he even started. I think this was
> not long before metamodel was put on
> ice fore a while.
>

To be honest, I had the same suggestion for HBMBinder as well even back in
the day to get out of second passes.  I think its a somewhat natural
paradigm for the type of problem domain here.



>
> > First, there is the general pros/cons of sequential processing versus
> > event-driven processing.  Some folks view event-driven processing as more
> > convoluted, harder to follow.
>
> It can not get much worse than following the 4k Binder as it stands now.
> Event based processing
> can sometimes be tricky. Maybe it would help in this case to document the
> approach and
> algorithm and the main actors. Either in the javadocs or maybe even better
> in an topical guide (more
> dev centric in this case).
>

True with the "it can't get much worse" aspect.  I think sequential
processing is fine/great if the thing you are doing is relatively simple.
 I think its safe to say that this is not simple :)


>
> > Anyway... thoughts? comments?
>
> For me it is also a question of time and resources. I agree that cleaning
> up the binding code would be
> awesome, but on the other hand I thought most of the details for binding
> the new metamodel had been
> sorted out by now. Is it worth rewriting now. On the other hand, if there
> are real issues with the code
> it might be worth the try.
>

I think "cleaning up" and "paradigm shift" are different beasts.  Yes
cleaning up can be done any time (even later) relatively easily.
 Completely shifting the underlying principles by which you attack a
problem is altogether different in my mind; I think the approach is best
ironed out from the onset.

That being said, a lot of the actual functionality is already in place.
 Its just a matter of organizing it slightly differently in most cases.

As for most cases being handled... well the 492 *uses* (not tests mind you,
uses equate to one or more tests) of FailureExpectedWithNewMetamodel would
beg to differ.  And that's not counting envers in any way which currently
has tons of failures because of the shift to metamodel.  Lots of things
simply do not work yet in metamodel.

From gbadner at redhat.com  Mon Apr 14 16:55:02 2014
From: gbadner at redhat.com (Gail Badner)
Date: Mon, 14 Apr 2014 16:55:02 -0400 (EDT)
Subject: [hibernate-dev] Some thoughts on possible Binder changes
In-Reply-To: <CAFdSV9uZAptq8bOT3GJnjU8hkBDsrr5qUFwCEpiq5GQHRNLj1g@mail.gmail.com>
References: <CAFdSV9ugvYJjrfbviMy80Wf6Lze82C27DcXBg8-hBcGD+O7xGg@mail.gmail.com>
	<8533C68B-4323-4A9C-828F-C581C56079B4@hibernate.org>
	<CAFdSV9uZAptq8bOT3GJnjU8hkBDsrr5qUFwCEpiq5GQHRNLj1g@mail.gmail.com>
Message-ID: <26592809.6902102.1397508902584.JavaMail.zimbra@redhat.com>

Also inline...

----- Original Message -----
> From: "Steve Ebersole" <steve at hibernate.org>
> To: "Hardy Ferentschik" <hardy at hibernate.org>
> Cc: "Hibernate" <hibernate-dev at lists.jboss.org>
> Sent: Saturday, April 12, 2014 11:55:28 AM
> Subject: Re: [hibernate-dev] Some thoughts on possible Binder changes
> 
> Thanks for the response.  See inline...
> 
> 
> On Sat, Apr 12, 2014 at 1:15 PM, Hardy Ferentschik
> <hardy at hibernate.org>wrote:
> 
> >
> > On 12 Jan 2014, at 18:56, Steve Ebersole <steve at hibernate.org> wrote:
> >
> > > The Background
> >
> > ...
> >
> > Thanks Steve, for this really nice summary. It is always good to share
> > some basic design/implementation
> > details.
> >
> > > In terms of dealing with composite ids, step (1) really just means
> > creating
> > > the Embeddable "shells" (the EmbeddableBinding instance).  But at this
> > > point the EmbeddableBinding is not done, we still need its attributes
> > > "resolved" or "bound".  To accomplish this, as Binder walks through the
> > > rest of the steps, it continually checks whether the completion of the
> > > attribute it just bound completes the binding of the Embeddable.  So as
> > it
> > > is looping over every attribute, for each attribute it loops over every
> > > known incomplete EmbeddableBinding and checks whether that attribute
> > > "completes" the EmbeddableBinding and if so finalizes it's binding.
> >

Yes, this is what it does. I agree there are better ways to deal with it. I thought the priority was to get functionality working ASAP. It was the easiest way to get it working at the time, and I figured we'd refine after the alpha.

> > What do you mean by "completes". How do you know that the
> > EmbeddableBinding is complete.
> >
> 
> For embeddables, this boils down to its sub-attributes being fully bound.
> Ultimately we need to be able to generate the Hibernate Type.  So looking
> at my example below, ultimately what we care about in regards to
> Person#address is the resolved Type for that attribute.
> 
> So here, "completes" is the verb form; the idea being simply.. was the
> attribute we just finished processing the last unresolved sub-attribute for
> a embeddable; did it "complete" the embeddable in terms of all its
> sub-attributes now being done.
> 
> As for how we know that, that depends.  In the existing Binder code we
> literally iterate the attributes making up the embeddable and see if the
> Type for all those sub-attributes has been resolved.
>  See
>  org.hibernate.metamodel.internal.binder.Binder#completeCompositeAttributeBindingIfPossible
> for the current process.
> 
> I am suggesting this change to use events as outlined below.
> 
> 
> 
> >
> > > Which got me to thinking about using events to signal the completion of
> > > things, and the ability to listen for these events.  Don't worry, I mean
> > > events here as fairly light weight concept :)
> >
> > For what it's worth, Strong had once the same idea. Instead of rechecking
> > and looping he also wanted to
> > introduce some sort of event based processing. I thought the idea sounded
> > promising.
> > I am not sure how far he got or whether he even started. I think this was
> > not long before metamodel was put on
> > ice fore a while.
> >
> 
> To be honest, I had the same suggestion for HBMBinder as well even back in
> the day to get out of second passes.  I think its a somewhat natural
> paradigm for the type of problem domain here.
>

I also remember Strong mentioning an events approach, but I think it was after embeddables were already working.
 
> 
> 
> >
> > > First, there is the general pros/cons of sequential processing versus
> > > event-driven processing.  Some folks view event-driven processing as more
> > > convoluted, harder to follow.
> >
> > It can not get much worse than following the 4k Binder as it stands now.
> > Event based processing
> > can sometimes be tricky. Maybe it would help in this case to document the
> > approach and
> > algorithm and the main actors. Either in the javadocs or maybe even better
> > in an topical guide (more
> > dev centric in this case).
> >
> 
> True with the "it can't get much worse" aspect.  I think sequential
> processing is fine/great if the thing you are doing is relatively simple.
>  I think its safe to say that this is not simple :)
> 
> 
> >
> > > Anyway... thoughts? comments?
> >
> > For me it is also a question of time and resources. I agree that cleaning
> > up the binding code would be
> > awesome, but on the other hand I thought most of the details for binding
> > the new metamodel had been
> > sorted out by now. Is it worth rewriting now. On the other hand, if there
> > are real issues with the code
> > it might be worth the try.
> >

I had also assumed that breaking up the Binder would be post-alpha.

> 
> I think "cleaning up" and "paradigm shift" are different beasts.  Yes
> cleaning up can be done any time (even later) relatively easily.
>  Completely shifting the underlying principles by which you attack a
> problem is altogether different in my mind; I think the approach is best
> ironed out from the onset.
> 
> That being said, a lot of the actual functionality is already in place.
>  Its just a matter of organizing it slightly differently in most cases.
>

I agree a paradigm shift is best as soon in the process as possible.
 
> As for most cases being handled... well the 492 *uses* (not tests mind you,
> uses equate to one or more tests) of FailureExpectedWithNewMetamodel would
> beg to differ.  And that's not counting envers in any way which currently
> has tons of failures because of the shift to metamodel.  Lots of things
> simply do not work yet in metamodel.

I would say that most things do work. Strong and I kept track of what was left by maintaining this document: https://github.com/hibernate/hibernate-orm/wiki/Failing-metamodel-tests . Steve, are you keeping this up-to-date?


> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> 

From steve at hibernate.org  Mon Apr 14 18:12:33 2014
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 14 Apr 2014 17:12:33 -0500
Subject: [hibernate-dev] Some thoughts on possible Binder changes
In-Reply-To: <26592809.6902102.1397508902584.JavaMail.zimbra@redhat.com>
References: <CAFdSV9ugvYJjrfbviMy80Wf6Lze82C27DcXBg8-hBcGD+O7xGg@mail.gmail.com>
	<8533C68B-4323-4A9C-828F-C581C56079B4@hibernate.org>
	<CAFdSV9uZAptq8bOT3GJnjU8hkBDsrr5qUFwCEpiq5GQHRNLj1g@mail.gmail.com>
	<26592809.6902102.1397508902584.JavaMail.zimbra@redhat.com>
Message-ID: <CAFdSV9u59nT98LdbynbPwC1SWBY5S_TtG4tPokWu-CQ_DKd9Fw@mail.gmail.com>

That document was last updated 9 months ago ("Last edited by Strong Liu, 9
months ago").  And in the interim we had the merge into master after which
we updated a BUNCH of tests to use @FailureExpectedWithNewMetamodel.  So I
am not sure how you think that is up to date.

TBH, I just go off of usage-searches for
the @FailureExpectedWithNewMetamodel annotation.  Initially I used that to
try and categorize the failures because most of the usages simply have
@FailureExpectedWithNewMetamodel() with no useful information (jiraKey or
message).  In general I noticed a lot of failures with composite ids, so
thats where I decided to start looking.

Sure, ideally we would refactor after having a more working set up.  But
you have to realize how this is for people coming into this code.  Just
take Binder.  Like I said, its 4K lines of hard to follow and essentially
non-documented, non-commented code.  That's not easy for someone to jump
into.  So in my efforts to understand what this code is supposed to be
doing in many places, combined with trying to solve missing or non-working
pieces of functionality I see some ways to improve it.

Take a simple example, like composite ids with IdClass.  At the moment the
code has no understanding that the IdClass mappings come from the entity;
essentially it tries to process it like it does any other composite.  This
is because everything routes through the same "build attribute binding"
code no matter where the attribute comes from.  I had already fixed this in
the annotation source code using a "attribute builder strategy" so I had
different strategies for the 3 different ways we needed to build
attributes.  So that's a natural paradigm to apply here.  It's is the same
failure, so its likely the same solution would work.  This is not
"refactoring, just to refactor"... this is refactoring to fix a problem.




On Mon, Apr 14, 2014 at 3:55 PM, Gail Badner <gbadner at redhat.com> wrote:

> Also inline...
>
> ----- Original Message -----
> > From: "Steve Ebersole" <steve at hibernate.org>
> > To: "Hardy Ferentschik" <hardy at hibernate.org>
> > Cc: "Hibernate" <hibernate-dev at lists.jboss.org>
> > Sent: Saturday, April 12, 2014 11:55:28 AM
> > Subject: Re: [hibernate-dev] Some thoughts on possible Binder changes
> >
> > Thanks for the response.  See inline...
> >
> >
> > On Sat, Apr 12, 2014 at 1:15 PM, Hardy Ferentschik
> > <hardy at hibernate.org>wrote:
> >
> > >
> > > On 12 Jan 2014, at 18:56, Steve Ebersole <steve at hibernate.org> wrote:
> > >
> > > > The Background
> > >
> > > ...
> > >
> > > Thanks Steve, for this really nice summary. It is always good to share
> > > some basic design/implementation
> > > details.
> > >
> > > > In terms of dealing with composite ids, step (1) really just means
> > > creating
> > > > the Embeddable "shells" (the EmbeddableBinding instance).  But at
> this
> > > > point the EmbeddableBinding is not done, we still need its attributes
> > > > "resolved" or "bound".  To accomplish this, as Binder walks through
> the
> > > > rest of the steps, it continually checks whether the completion of
> the
> > > > attribute it just bound completes the binding of the Embeddable.  So
> as
> > > it
> > > > is looping over every attribute, for each attribute it loops over
> every
> > > > known incomplete EmbeddableBinding and checks whether that attribute
> > > > "completes" the EmbeddableBinding and if so finalizes it's binding.
> > >
>
> Yes, this is what it does. I agree there are better ways to deal with it.
> I thought the priority was to get functionality working ASAP. It was the
> easiest way to get it working at the time, and I figured we'd refine after
> the alpha.
>
> > > What do you mean by "completes". How do you know that the
> > > EmbeddableBinding is complete.
> > >
> >
> > For embeddables, this boils down to its sub-attributes being fully bound.
> > Ultimately we need to be able to generate the Hibernate Type.  So looking
> > at my example below, ultimately what we care about in regards to
> > Person#address is the resolved Type for that attribute.
> >
> > So here, "completes" is the verb form; the idea being simply.. was the
> > attribute we just finished processing the last unresolved sub-attribute
> for
> > a embeddable; did it "complete" the embeddable in terms of all its
> > sub-attributes now being done.
> >
> > As for how we know that, that depends.  In the existing Binder code we
> > literally iterate the attributes making up the embeddable and see if the
> > Type for all those sub-attributes has been resolved.
> >  See
> >
>  org.hibernate.metamodel.internal.binder.Binder#completeCompositeAttributeBindingIfPossible
> > for the current process.
> >
> > I am suggesting this change to use events as outlined below.
> >
> >
> >
> > >
> > > > Which got me to thinking about using events to signal the completion
> of
> > > > things, and the ability to listen for these events.  Don't worry, I
> mean
> > > > events here as fairly light weight concept :)
> > >
> > > For what it's worth, Strong had once the same idea. Instead of
> rechecking
> > > and looping he also wanted to
> > > introduce some sort of event based processing. I thought the idea
> sounded
> > > promising.
> > > I am not sure how far he got or whether he even started. I think this
> was
> > > not long before metamodel was put on
> > > ice fore a while.
> > >
> >
> > To be honest, I had the same suggestion for HBMBinder as well even back
> in
> > the day to get out of second passes.  I think its a somewhat natural
> > paradigm for the type of problem domain here.
> >
>
> I also remember Strong mentioning an events approach, but I think it was
> after embeddables were already working.
>
> >
> >
> > >
> > > > First, there is the general pros/cons of sequential processing versus
> > > > event-driven processing.  Some folks view event-driven processing as
> more
> > > > convoluted, harder to follow.
> > >
> > > It can not get much worse than following the 4k Binder as it stands
> now.
> > > Event based processing
> > > can sometimes be tricky. Maybe it would help in this case to document
> the
> > > approach and
> > > algorithm and the main actors. Either in the javadocs or maybe even
> better
> > > in an topical guide (more
> > > dev centric in this case).
> > >
> >
> > True with the "it can't get much worse" aspect.  I think sequential
> > processing is fine/great if the thing you are doing is relatively simple.
> >  I think its safe to say that this is not simple :)
> >
> >
> > >
> > > > Anyway... thoughts? comments?
> > >
> > > For me it is also a question of time and resources. I agree that
> cleaning
> > > up the binding code would be
> > > awesome, but on the other hand I thought most of the details for
> binding
> > > the new metamodel had been
> > > sorted out by now. Is it worth rewriting now. On the other hand, if
> there
> > > are real issues with the code
> > > it might be worth the try.
> > >
>
> I had also assumed that breaking up the Binder would be post-alpha.
>
> >
> > I think "cleaning up" and "paradigm shift" are different beasts.  Yes
> > cleaning up can be done any time (even later) relatively easily.
> >  Completely shifting the underlying principles by which you attack a
> > problem is altogether different in my mind; I think the approach is best
> > ironed out from the onset.
> >
> > That being said, a lot of the actual functionality is already in place.
> >  Its just a matter of organizing it slightly differently in most cases.
> >
>
> I agree a paradigm shift is best as soon in the process as possible.
>
> > As for most cases being handled... well the 492 *uses* (not tests mind
> you,
> > uses equate to one or more tests) of FailureExpectedWithNewMetamodel
> would
> > beg to differ.  And that's not counting envers in any way which currently
> > has tons of failures because of the shift to metamodel.  Lots of things
> > simply do not work yet in metamodel.
>
> I would say that most things do work. Strong and I kept track of what was
> left by maintaining this document:
> https://github.com/hibernate/hibernate-orm/wiki/Failing-metamodel-tests .
> Steve, are you keeping this up-to-date?
>
>
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
>

From steve at hibernate.org  Tue Apr 15 12:41:05 2014
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 15 Apr 2014 11:41:05 -0500
Subject: [hibernate-dev] IRC Developer Meeting - 4/15
Message-ID: <CAFdSV9sBtVeb=KY=A6BAh0nV40D3kwdZxy3pD0as5Gh7rwB1Lw@mail.gmail.com>

Mainly discussed:
1) Java 8 support
2) 5.0 development

[11:39] <jbott> Meeting ended Tue Apr 15 16:25:10 2014 UTC.  Information
about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
[11:39] <jbott> Minutes:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2014/hibernate-dev.2014-04-15-14.45.html
[11:39] <jbott> Minutes (text):
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2014/hibernate-dev.2014-04-15-14.45.txt
[11:39] <jbott> Log:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2014/hibernate-dev.2014-04-15-14.45.log.html

From steve at hibernate.org  Tue Apr 15 22:25:28 2014
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 15 Apr 2014 21:25:28 -0500
Subject: [hibernate-dev] Some thoughts on possible Binder changes
In-Reply-To: <CAFdSV9u59nT98LdbynbPwC1SWBY5S_TtG4tPokWu-CQ_DKd9Fw@mail.gmail.com>
References: <CAFdSV9ugvYJjrfbviMy80Wf6Lze82C27DcXBg8-hBcGD+O7xGg@mail.gmail.com>
	<8533C68B-4323-4A9C-828F-C581C56079B4@hibernate.org>
	<CAFdSV9uZAptq8bOT3GJnjU8hkBDsrr5qUFwCEpiq5GQHRNLj1g@mail.gmail.com>
	<26592809.6902102.1397508902584.JavaMail.zimbra@redhat.com>
	<CAFdSV9u59nT98LdbynbPwC1SWBY5S_TtG4tPokWu-CQ_DKd9Fw@mail.gmail.com>
Message-ID: <CAFdSV9sCjwnP25+-rWM=Qw0UmUM=cg7kLjaubxrV8sQeXc8Wdg@mail.gmail.com>

After discussing this and the current process some more with Gail on IRC I
have a more clear understanding of exactly what is needed here.  Hardy, the
clarification ties directly with your question: What is "complete"?  In
other words, what exactly are the events used to signify?

The answer is complete resolution of a Type.  The state of Type resolution
as we build the "binding model" is encapsulated in the
HibernateTypeDescriptor class.  Ultimately the "event" we are interested in
is the call to HibernateTypeDescriptor#setResolvedTypeMapping(Type).  This
is the event that signals that an attribute is fully resolved.  At that
point it is ok to access its Type (obviously), its relational bindings,
etc.  HibernateTypeDescriptor is associated with each and every attribute
via AttributeBinding#getHibernateTypeDescriptor.  Some other things besides
attributes have HibernateTypeDescriptor associated with them also (some
special id cases, collection elements, map keys, etc).

The question then becomes how to model this.  The first "difficulty" is
that most things understand their dependence on a Type through an
Attribute; but HibernateTypeDescriptor does not know the attribute (or
collection element or ..) it "comes from".  I have added a listener for the
HibernateTypeDescriptor#setResolvedTypeMapping call in the
HibernateTypeDescriptor, but that still does not get us the ability to
route this back to things that are interested in this condition.  Let's
take a look back at the Person/Address/Zip example as an illustration.
 When we process Person#address we cannot fully resolve the CompositeType
here because the sub-attributes (street, zip, etc) have not yet been bound.
 So we'd register interest in those attributes becoming complete to
finalize the Person#address attribute.  But we can't just add a listener to
the HibernateTypeDescriptor associated with each of those sub-attribute
bindings... the sub-attribute bindings don't exist yet.

Here's another situation:

@Entity
class Order {
  @EmbeddedId
  OrderPk pk;

  @MapsId
  @ManyToOne
  Customer customer;

  ...
}

@Entity
class LineItem {
  ...

  @ManyToOne
  Order order;
}

Here the situation is that the identifier for Order cannot be fully
resolved "up front" because of the @MapsId.  Thus resolution of the
Orderentity is dependent on the resolution of its "normal" attribute
customer.  We could mitigate this somewhat by saying that @MapsId attributes
are handled specially, when we handle identifiers; but lets for now say we
leave it as-is...  So we'd need to register a listener to finalize the
Orderidentifier resolution when
customer is finalized.  Again notice that when processing the
Orderidentifier, the attribute binding for
customer does not yet exist, so we can't directly add a listener to
the HibernateTypeDescriptor.
 A similar situation exists for the LineItem order attribute in that it
will need to wait for the Order identifier to be finalized.


The most straight forward approach for bridging HibernateTypeDescriptor and
AttributeBinding would be a whiteboard pattern.  Have a third party
(Binder) be the listener for all HibernateTypeDescriptor for all created
attribute bindings.  It would maintain a map of HibernateTypeDescriptor ->
AttributeBinding.  An alternative would be to make
AttributeBinding#getHibernateTypeDescriptor "bi directional".  But the
externalized mapping allows for some flexibility in the "sources of
HibernateTypeDescriptor that are not an attribute" cases I mentioned
earlier.  Anyway, this third part delegate would listen for
HibernateTypeDescriptor#setResolvedTypeMapping events (which get passed the
HibernateTypeDescriptor) and map that to listener calls based on the
AttributeBinding.

Its maybe not the cleanest solution.  I think (longer term?) I'd really
like to make the binding model immutable after creation the way it was
initially intended when we started down the metamodel path.  But given the
mutable in-flight binding model solution in place, any better suggestions
for handling this?




On Mon, Apr 14, 2014 at 5:12 PM, Steve Ebersole <steve at hibernate.org> wrote:

> That document was last updated 9 months ago ("Last edited by Strong Liu, 9
> months ago").  And in the interim we had the merge into master after which
> we updated a BUNCH of tests to use @FailureExpectedWithNewMetamodel.  So I
> am not sure how you think that is up to date.
>
> TBH, I just go off of usage-searches for
> the @FailureExpectedWithNewMetamodel annotation.  Initially I used that to
> try and categorize the failures because most of the usages simply have
> @FailureExpectedWithNewMetamodel() with no useful information (jiraKey or
> message).  In general I noticed a lot of failures with composite ids, so
> thats where I decided to start looking.
>
> Sure, ideally we would refactor after having a more working set up.  But
> you have to realize how this is for people coming into this code.  Just
> take Binder.  Like I said, its 4K lines of hard to follow and essentially
> non-documented, non-commented code.  That's not easy for someone to jump
> into.  So in my efforts to understand what this code is supposed to be
> doing in many places, combined with trying to solve missing or non-working
> pieces of functionality I see some ways to improve it.
>
> Take a simple example, like composite ids with IdClass.  At the moment the
> code has no understanding that the IdClass mappings come from the entity;
> essentially it tries to process it like it does any other composite.  This
> is because everything routes through the same "build attribute binding"
> code no matter where the attribute comes from.  I had already fixed this in
> the annotation source code using a "attribute builder strategy" so I had
> different strategies for the 3 different ways we needed to build
> attributes.  So that's a natural paradigm to apply here.  It's is the same
> failure, so its likely the same solution would work.  This is not
> "refactoring, just to refactor"... this is refactoring to fix a problem.
>
>
>
>
> On Mon, Apr 14, 2014 at 3:55 PM, Gail Badner <gbadner at redhat.com> wrote:
>
>> Also inline...
>>
>> ----- Original Message -----
>> > From: "Steve Ebersole" <steve at hibernate.org>
>> > To: "Hardy Ferentschik" <hardy at hibernate.org>
>> > Cc: "Hibernate" <hibernate-dev at lists.jboss.org>
>> > Sent: Saturday, April 12, 2014 11:55:28 AM
>> > Subject: Re: [hibernate-dev] Some thoughts on possible Binder changes
>> >
>> > Thanks for the response.  See inline...
>> >
>> >
>> > On Sat, Apr 12, 2014 at 1:15 PM, Hardy Ferentschik
>> > <hardy at hibernate.org>wrote:
>> >
>> > >
>> > > On 12 Jan 2014, at 18:56, Steve Ebersole <steve at hibernate.org> wrote:
>> > >
>> > > > The Background
>> > >
>> > > ...
>> > >
>> > > Thanks Steve, for this really nice summary. It is always good to share
>> > > some basic design/implementation
>> > > details.
>> > >
>> > > > In terms of dealing with composite ids, step (1) really just means
>> > > creating
>> > > > the Embeddable "shells" (the EmbeddableBinding instance).  But at
>> this
>> > > > point the EmbeddableBinding is not done, we still need its
>> attributes
>> > > > "resolved" or "bound".  To accomplish this, as Binder walks through
>> the
>> > > > rest of the steps, it continually checks whether the completion of
>> the
>> > > > attribute it just bound completes the binding of the Embeddable.
>>  So as
>> > > it
>> > > > is looping over every attribute, for each attribute it loops over
>> every
>> > > > known incomplete EmbeddableBinding and checks whether that attribute
>> > > > "completes" the EmbeddableBinding and if so finalizes it's binding.
>> > >
>>
>> Yes, this is what it does. I agree there are better ways to deal with it.
>> I thought the priority was to get functionality working ASAP. It was the
>> easiest way to get it working at the time, and I figured we'd refine after
>> the alpha.
>>
>> > > What do you mean by "completes". How do you know that the
>> > > EmbeddableBinding is complete.
>> > >
>> >
>> > For embeddables, this boils down to its sub-attributes being fully
>> bound.
>> > Ultimately we need to be able to generate the Hibernate Type.  So
>> looking
>> > at my example below, ultimately what we care about in regards to
>> > Person#address is the resolved Type for that attribute.
>> >
>> > So here, "completes" is the verb form; the idea being simply.. was the
>> > attribute we just finished processing the last unresolved sub-attribute
>> for
>> > a embeddable; did it "complete" the embeddable in terms of all its
>> > sub-attributes now being done.
>> >
>> > As for how we know that, that depends.  In the existing Binder code we
>> > literally iterate the attributes making up the embeddable and see if the
>> > Type for all those sub-attributes has been resolved.
>> >  See
>> >
>>  org.hibernate.metamodel.internal.binder.Binder#completeCompositeAttributeBindingIfPossible
>> > for the current process.
>> >
>> > I am suggesting this change to use events as outlined below.
>> >
>> >
>> >
>> > >
>> > > > Which got me to thinking about using events to signal the
>> completion of
>> > > > things, and the ability to listen for these events.  Don't worry, I
>> mean
>> > > > events here as fairly light weight concept :)
>> > >
>> > > For what it's worth, Strong had once the same idea. Instead of
>> rechecking
>> > > and looping he also wanted to
>> > > introduce some sort of event based processing. I thought the idea
>> sounded
>> > > promising.
>> > > I am not sure how far he got or whether he even started. I think this
>> was
>> > > not long before metamodel was put on
>> > > ice fore a while.
>> > >
>> >
>> > To be honest, I had the same suggestion for HBMBinder as well even back
>> in
>> > the day to get out of second passes.  I think its a somewhat natural
>> > paradigm for the type of problem domain here.
>> >
>>
>> I also remember Strong mentioning an events approach, but I think it was
>> after embeddables were already working.
>>
>> >
>> >
>> > >
>> > > > First, there is the general pros/cons of sequential processing
>> versus
>> > > > event-driven processing.  Some folks view event-driven processing
>> as more
>> > > > convoluted, harder to follow.
>> > >
>> > > It can not get much worse than following the 4k Binder as it stands
>> now.
>> > > Event based processing
>> > > can sometimes be tricky. Maybe it would help in this case to document
>> the
>> > > approach and
>> > > algorithm and the main actors. Either in the javadocs or maybe even
>> better
>> > > in an topical guide (more
>> > > dev centric in this case).
>> > >
>> >
>> > True with the "it can't get much worse" aspect.  I think sequential
>> > processing is fine/great if the thing you are doing is relatively
>> simple.
>> >  I think its safe to say that this is not simple :)
>> >
>> >
>> > >
>> > > > Anyway... thoughts? comments?
>> > >
>> > > For me it is also a question of time and resources. I agree that
>> cleaning
>> > > up the binding code would be
>> > > awesome, but on the other hand I thought most of the details for
>> binding
>> > > the new metamodel had been
>> > > sorted out by now. Is it worth rewriting now. On the other hand, if
>> there
>> > > are real issues with the code
>> > > it might be worth the try.
>> > >
>>
>> I had also assumed that breaking up the Binder would be post-alpha.
>>
>> >
>> > I think "cleaning up" and "paradigm shift" are different beasts.  Yes
>> > cleaning up can be done any time (even later) relatively easily.
>> >  Completely shifting the underlying principles by which you attack a
>> > problem is altogether different in my mind; I think the approach is best
>> > ironed out from the onset.
>> >
>> > That being said, a lot of the actual functionality is already in place.
>> >  Its just a matter of organizing it slightly differently in most cases.
>> >
>>
>> I agree a paradigm shift is best as soon in the process as possible.
>>
>> > As for most cases being handled... well the 492 *uses* (not tests mind
>> you,
>> > uses equate to one or more tests) of FailureExpectedWithNewMetamodel
>> would
>> > beg to differ.  And that's not counting envers in any way which
>> currently
>> > has tons of failures because of the shift to metamodel.  Lots of things
>> > simply do not work yet in metamodel.
>>
>> I would say that most things do work. Strong and I kept track of what was
>> left by maintaining this document:
>> https://github.com/hibernate/hibernate-orm/wiki/Failing-metamodel-tests. Steve, are you keeping this up-to-date?
>>
>>
>> > _______________________________________________
>> > hibernate-dev mailing list
>> > hibernate-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >
>>
>
>

From emmanuel at hibernate.org  Thu Apr 17 08:04:20 2014
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Thu, 17 Apr 2014 14:04:20 +0200
Subject: [hibernate-dev] Hibernate OGM 4.1 Beta 2
Message-ID: <44EAAF6F-AADD-487D-8E4B-38C3862320E4@hibernate.org>

Bam. A new release from the Hibernate OGM development team.

In a nutshell:
- wildfly and JBossEAP modules 
- many bug fixes and improvements (MongoDB, queries, collection, etc)

Go, go, go!
http://in.relation.to/Bloggers/HibernateOGM41Beta2WildFlyAndJBossEAPModules

Emmanuel

From steve at hibernate.org  Thu Apr 17 12:05:23 2014
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 17 Apr 2014 11:05:23 -0500
Subject: [hibernate-dev] Loggers and categories
Message-ID: <CAFdSV9sccUDe1d6ED2K_sjwrjtQWpuERvGjgF0ZZgdbvsoKkrA@mail.gmail.com>

Wanted to revisit something that's been bothering me ever since we moved to
JBoss Logging : the definition of loggers.

While I think we have always understood that there are really 2 different
audiences for log messages, I think I have come to have a more clear
understanding of what that means and its implications.

We have log messages intended for usage scenarios and log messages intended
for debugging scenarios.  To me, the first groups is represented by the
JBoss Logging MessageLogger messages.  The second group are the things we
simply "pass through" to the underlying log backend (trace, debug messages).

In both cases we currently use the name of the Class initiating the log
message as the "category name".  While I think that is absolutely the
correct thing to do in the case of that second group, what about the first
group?  For that first group I wonder if its better to have "logical
category names" more like 'org.hibernate.orm.deprecations' and
'org.hibernate.orm.mapping'...  The idea being that its easier to switch
these grouped categories on/off.

From steve at hibernate.org  Thu Apr 17 12:48:21 2014
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 17 Apr 2014 11:48:21 -0500
Subject: [hibernate-dev] Some thoughts on possible Binder changes
In-Reply-To: <CAFdSV9sCjwnP25+-rWM=Qw0UmUM=cg7kLjaubxrV8sQeXc8Wdg@mail.gmail.com>
References: <CAFdSV9ugvYJjrfbviMy80Wf6Lze82C27DcXBg8-hBcGD+O7xGg@mail.gmail.com>
	<8533C68B-4323-4A9C-828F-C581C56079B4@hibernate.org>
	<CAFdSV9uZAptq8bOT3GJnjU8hkBDsrr5qUFwCEpiq5GQHRNLj1g@mail.gmail.com>
	<26592809.6902102.1397508902584.JavaMail.zimbra@redhat.com>
	<CAFdSV9u59nT98LdbynbPwC1SWBY5S_TtG4tPokWu-CQ_DKd9Fw@mail.gmail.com>
	<CAFdSV9sCjwnP25+-rWM=Qw0UmUM=cg7kLjaubxrV8sQeXc8Wdg@mail.gmail.com>
Message-ID: <CAFdSV9udP_kcM8FF61A-4QjixAe_Y54zNLJcEyF5UJQ8iv0ijw@mail.gmail.com>

Some more follow-up on this...

Ordered processing of entity hierarchies based on id dependencies

One of the "wait on" scenarios I discussed above where events would help is
in the case of identifier which are made up of one or more many-to-one
associations.  What ends up happening currently is that we iterate the
entity hierarchies in a undefined order.  So in a normal Customer/Order
like described in the earlier emails, its possible that we process Order
before we process Customer.  One thing I just finished as a pre-step
(during the indexing we do of the sources anyway) was to build an ordered
list of the hierarchies based on the to-one dependencies expressed by their
identifiers.  I am not sure this works in all cases yet, but its at least a
best effort.


@MapsId attributes

In the case of EmbeddedId composite ids, we also have this notion in JPA of
"maps-id":

@Embeddable
class OrderPK implements Serializable {
  public Integer customerId;
  public Integer orderNumber;
  ...
}

@Entity
class Customer {
  @Id
  private Integer id;
  ..
}

@Entity
class Order {
  @EmbeddedId
  private OrderPK pk;

  @MapsId("customerId")
  @ManyToOne
  private Customer customer;

  ...
}

@MapsId is accounted for when determining the "ordered processing of entity
hierarchies based on id dependencies".  However, there is still some
difficulty here in that Binder tries to process all identifiers before
moving on to "non-identifier" attributes.  Atm it does not consider
@MapsId attributes
to be part of the "identifier".  The trouble comes from the fact that we
need to have the Order#customer attribute resolved before we can fully
resolve the Order identifier.

One proposal to get around that is that we process attributes marked as
@MapsId as we process the identifiers in terms of binding.  In the binding
model, there would still be a non-identifier attribute for Order#customer;
I just am talking about timing in the Binder.  The other option is to wait
using events; though that seems far more likely to lead to indefinite wait
scenarios.




On Tue, Apr 15, 2014 at 9:25 PM, Steve Ebersole <steve at hibernate.org> wrote:

> After discussing this and the current process some more with Gail on IRC I
> have a more clear understanding of exactly what is needed here.  Hardy, the
> clarification ties directly with your question: What is "complete"?  In
> other words, what exactly are the events used to signify?
>
> The answer is complete resolution of a Type.  The state of Type resolution
> as we build the "binding model" is encapsulated in the
> HibernateTypeDescriptor class.  Ultimately the "event" we are interested in
> is the call to HibernateTypeDescriptor#setResolvedTypeMapping(Type).  This
> is the event that signals that an attribute is fully resolved.  At that
> point it is ok to access its Type (obviously), its relational bindings,
> etc.  HibernateTypeDescriptor is associated with each and every attribute
> via AttributeBinding#getHibernateTypeDescriptor.  Some other things besides
> attributes have HibernateTypeDescriptor associated with them also (some
> special id cases, collection elements, map keys, etc).
>
> The question then becomes how to model this.  The first "difficulty" is
> that most things understand their dependence on a Type through an
> Attribute; but HibernateTypeDescriptor does not know the attribute (or
> collection element or ..) it "comes from".  I have added a listener for the
> HibernateTypeDescriptor#setResolvedTypeMapping call in the
> HibernateTypeDescriptor, but that still does not get us the ability to
> route this back to things that are interested in this condition.  Let's
> take a look back at the Person/Address/Zip example as an illustration.
>  When we process Person#address we cannot fully resolve the CompositeType
> here because the sub-attributes (street, zip, etc) have not yet been bound.
>  So we'd register interest in those attributes becoming complete to
> finalize the Person#address attribute.  But we can't just add a listener to
> the HibernateTypeDescriptor associated with each of those sub-attribute
> bindings... the sub-attribute bindings don't exist yet.
>
> Here's another situation:
>
> @Entity
> class Order {
>   @EmbeddedId
>   OrderPk pk;
>
>   @MapsId
>   @ManyToOne
>   Customer customer;
>
>   ...
> }
>
> @Entity
> class LineItem {
>   ...
>
>   @ManyToOne
>   Order order;
> }
>
> Here the situation is that the identifier for Order cannot be fully
> resolved "up front" because of the @MapsId.  Thus resolution of the Orderentity is dependent on the resolution of its "normal" attribute
> customer.  We could mitigate this somewhat by saying that @MapsId attributes
> are handled specially, when we handle identifiers; but lets for now say we
> leave it as-is...  So we'd need to register a listener to finalize the
> Order identifier resolution when customer is finalized.  Again notice
> that when processing the Order identifier, the attribute binding for
> customer does not yet exist, so we can't directly add a listener to the HibernateTypeDescriptor.
>  A similar situation exists for the LineItem order attribute in that it
> will need to wait for the Order identifier to be finalized.
>
>
> The most straight forward approach for bridging HibernateTypeDescriptor
> and AttributeBinding would be a whiteboard pattern.  Have a third party
> (Binder) be the listener for all HibernateTypeDescriptor for all created
> attribute bindings.  It would maintain a map of HibernateTypeDescriptor ->
> AttributeBinding.  An alternative would be to make
> AttributeBinding#getHibernateTypeDescriptor "bi directional".  But the
> externalized mapping allows for some flexibility in the "sources of
> HibernateTypeDescriptor that are not an attribute" cases I mentioned
> earlier.  Anyway, this third part delegate would listen for
> HibernateTypeDescriptor#setResolvedTypeMapping events (which get passed the
> HibernateTypeDescriptor) and map that to listener calls based on the
> AttributeBinding.
>
> Its maybe not the cleanest solution.  I think (longer term?) I'd really
> like to make the binding model immutable after creation the way it was
> initially intended when we started down the metamodel path.  But given the
> mutable in-flight binding model solution in place, any better suggestions
> for handling this?
>
>
>
>
> On Mon, Apr 14, 2014 at 5:12 PM, Steve Ebersole <steve at hibernate.org>wrote:
>
>> That document was last updated 9 months ago ("Last edited by Strong Liu,
>> 9 months ago").  And in the interim we had the merge into master after
>> which we updated a BUNCH of tests to use @FailureExpectedWithNewMetamodel.
>>  So I am not sure how you think that is up to date.
>>
>> TBH, I just go off of usage-searches for
>> the @FailureExpectedWithNewMetamodel annotation.  Initially I used that to
>> try and categorize the failures because most of the usages simply have
>> @FailureExpectedWithNewMetamodel() with no useful information (jiraKey or
>> message).  In general I noticed a lot of failures with composite ids, so
>> thats where I decided to start looking.
>>
>> Sure, ideally we would refactor after having a more working set up.  But
>> you have to realize how this is for people coming into this code.  Just
>> take Binder.  Like I said, its 4K lines of hard to follow and essentially
>> non-documented, non-commented code.  That's not easy for someone to jump
>> into.  So in my efforts to understand what this code is supposed to be
>> doing in many places, combined with trying to solve missing or non-working
>> pieces of functionality I see some ways to improve it.
>>
>> Take a simple example, like composite ids with IdClass.  At the moment
>> the code has no understanding that the IdClass mappings come from the
>> entity; essentially it tries to process it like it does any other
>> composite.  This is because everything routes through the same "build
>> attribute binding" code no matter where the attribute comes from.  I had
>> already fixed this in the annotation source code using a "attribute builder
>> strategy" so I had different strategies for the 3 different ways we needed
>> to build attributes.  So that's a natural paradigm to apply here.  It's is
>> the same failure, so its likely the same solution would work.  This is not
>> "refactoring, just to refactor"... this is refactoring to fix a problem.
>>
>>
>>
>>
>> On Mon, Apr 14, 2014 at 3:55 PM, Gail Badner <gbadner at redhat.com> wrote:
>>
>>> Also inline...
>>>
>>> ----- Original Message -----
>>> > From: "Steve Ebersole" <steve at hibernate.org>
>>> > To: "Hardy Ferentschik" <hardy at hibernate.org>
>>> > Cc: "Hibernate" <hibernate-dev at lists.jboss.org>
>>> > Sent: Saturday, April 12, 2014 11:55:28 AM
>>> > Subject: Re: [hibernate-dev] Some thoughts on possible Binder changes
>>> >
>>> > Thanks for the response.  See inline...
>>> >
>>> >
>>> > On Sat, Apr 12, 2014 at 1:15 PM, Hardy Ferentschik
>>> > <hardy at hibernate.org>wrote:
>>> >
>>> > >
>>> > > On 12 Jan 2014, at 18:56, Steve Ebersole <steve at hibernate.org>
>>> wrote:
>>> > >
>>> > > > The Background
>>> > >
>>> > > ...
>>> > >
>>> > > Thanks Steve, for this really nice summary. It is always good to
>>> share
>>> > > some basic design/implementation
>>> > > details.
>>> > >
>>> > > > In terms of dealing with composite ids, step (1) really just means
>>> > > creating
>>> > > > the Embeddable "shells" (the EmbeddableBinding instance).  But at
>>> this
>>> > > > point the EmbeddableBinding is not done, we still need its
>>> attributes
>>> > > > "resolved" or "bound".  To accomplish this, as Binder walks
>>> through the
>>> > > > rest of the steps, it continually checks whether the completion of
>>> the
>>> > > > attribute it just bound completes the binding of the Embeddable.
>>>  So as
>>> > > it
>>> > > > is looping over every attribute, for each attribute it loops over
>>> every
>>> > > > known incomplete EmbeddableBinding and checks whether that
>>> attribute
>>> > > > "completes" the EmbeddableBinding and if so finalizes it's binding.
>>> > >
>>>
>>> Yes, this is what it does. I agree there are better ways to deal with
>>> it. I thought the priority was to get functionality working ASAP. It was
>>> the easiest way to get it working at the time, and I figured we'd refine
>>> after the alpha.
>>>
>>> > > What do you mean by "completes". How do you know that the
>>> > > EmbeddableBinding is complete.
>>> > >
>>> >
>>> > For embeddables, this boils down to its sub-attributes being fully
>>> bound.
>>> > Ultimately we need to be able to generate the Hibernate Type.  So
>>> looking
>>> > at my example below, ultimately what we care about in regards to
>>> > Person#address is the resolved Type for that attribute.
>>> >
>>> > So here, "completes" is the verb form; the idea being simply.. was the
>>> > attribute we just finished processing the last unresolved
>>> sub-attribute for
>>> > a embeddable; did it "complete" the embeddable in terms of all its
>>> > sub-attributes now being done.
>>> >
>>> > As for how we know that, that depends.  In the existing Binder code we
>>> > literally iterate the attributes making up the embeddable and see if
>>> the
>>> > Type for all those sub-attributes has been resolved.
>>> >  See
>>> >
>>>  org.hibernate.metamodel.internal.binder.Binder#completeCompositeAttributeBindingIfPossible
>>> > for the current process.
>>> >
>>> > I am suggesting this change to use events as outlined below.
>>> >
>>> >
>>> >
>>> > >
>>> > > > Which got me to thinking about using events to signal the
>>> completion of
>>> > > > things, and the ability to listen for these events.  Don't worry,
>>> I mean
>>> > > > events here as fairly light weight concept :)
>>> > >
>>> > > For what it's worth, Strong had once the same idea. Instead of
>>> rechecking
>>> > > and looping he also wanted to
>>> > > introduce some sort of event based processing. I thought the idea
>>> sounded
>>> > > promising.
>>> > > I am not sure how far he got or whether he even started. I think
>>> this was
>>> > > not long before metamodel was put on
>>> > > ice fore a while.
>>> > >
>>> >
>>> > To be honest, I had the same suggestion for HBMBinder as well even
>>> back in
>>> > the day to get out of second passes.  I think its a somewhat natural
>>> > paradigm for the type of problem domain here.
>>> >
>>>
>>> I also remember Strong mentioning an events approach, but I think it was
>>> after embeddables were already working.
>>>
>>> >
>>> >
>>> > >
>>> > > > First, there is the general pros/cons of sequential processing
>>> versus
>>> > > > event-driven processing.  Some folks view event-driven processing
>>> as more
>>> > > > convoluted, harder to follow.
>>> > >
>>> > > It can not get much worse than following the 4k Binder as it stands
>>> now.
>>> > > Event based processing
>>> > > can sometimes be tricky. Maybe it would help in this case to
>>> document the
>>> > > approach and
>>> > > algorithm and the main actors. Either in the javadocs or maybe even
>>> better
>>> > > in an topical guide (more
>>> > > dev centric in this case).
>>> > >
>>> >
>>> > True with the "it can't get much worse" aspect.  I think sequential
>>> > processing is fine/great if the thing you are doing is relatively
>>> simple.
>>> >  I think its safe to say that this is not simple :)
>>> >
>>> >
>>> > >
>>> > > > Anyway... thoughts? comments?
>>> > >
>>> > > For me it is also a question of time and resources. I agree that
>>> cleaning
>>> > > up the binding code would be
>>> > > awesome, but on the other hand I thought most of the details for
>>> binding
>>> > > the new metamodel had been
>>> > > sorted out by now. Is it worth rewriting now. On the other hand, if
>>> there
>>> > > are real issues with the code
>>> > > it might be worth the try.
>>> > >
>>>
>>> I had also assumed that breaking up the Binder would be post-alpha.
>>>
>>> >
>>> > I think "cleaning up" and "paradigm shift" are different beasts.  Yes
>>> > cleaning up can be done any time (even later) relatively easily.
>>> >  Completely shifting the underlying principles by which you attack a
>>> > problem is altogether different in my mind; I think the approach is
>>> best
>>> > ironed out from the onset.
>>> >
>>> > That being said, a lot of the actual functionality is already in place.
>>> >  Its just a matter of organizing it slightly differently in most cases.
>>> >
>>>
>>> I agree a paradigm shift is best as soon in the process as possible.
>>>
>>> > As for most cases being handled... well the 492 *uses* (not tests mind
>>> you,
>>> > uses equate to one or more tests) of FailureExpectedWithNewMetamodel
>>> would
>>> > beg to differ.  And that's not counting envers in any way which
>>> currently
>>> > has tons of failures because of the shift to metamodel.  Lots of things
>>> > simply do not work yet in metamodel.
>>>
>>> I would say that most things do work. Strong and I kept track of what
>>> was left by maintaining this document:
>>> https://github.com/hibernate/hibernate-orm/wiki/Failing-metamodel-tests. Steve, are you keeping this up-to-date?
>>>
>>>
>>> > _______________________________________________
>>> > hibernate-dev mailing list
>>> > hibernate-dev at lists.jboss.org
>>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>> >
>>>
>>
>>
>

From steve at hibernate.org  Fri Apr 18 10:47:27 2014
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 18 Apr 2014 09:47:27 -0500
Subject: [hibernate-dev] 5.0 metamodel binding
In-Reply-To: <1179022439.3853790.1397082246356.JavaMail.zimbra@redhat.com>
References: <CAFdSV9tdD=47o0xf2BnTcaXEd=1HTEcyF=RP6wGLVKhMwNoR9w@mail.gmail.com>
	<22DD4F7E-7BAB-41F9-9C64-F5A658FE0D3E@hibernate.org>
	<1179022439.3853790.1397082246356.JavaMail.zimbra@redhat.com>
Message-ID: <CAFdSV9v+qrXQ2S9s-4RjzobV-Q8=e9uiF1dZwpWsz9P4DZ7Oyw@mail.gmail.com>

Like we discussed on IRC, the intention of
Attribute#getAttributeContainer() (as
indicated by javadocs) is to return the *declaring* attribute container.


On Wed, Apr 9, 2014 at 5:24 PM, Gail Badner <gbadner at redhat.com> wrote:

> Envers looks at @MappedSuperclass ClassInfo to see if it has any
> attributes that are audited. If it finds one, then Envers has to find the
> corresponding AttributeBinding in the EntityBinding to get it's access
> type, column names, etc.
>
> I don't think it really requires a MappedSuperclassBinding, but tweaking
> the domain model would help.
>
> I think adding a method like this will provide enough information:
>
>     javax.persistence.metamodel.Attribute.getDeclaringType() returning
> ManagedType<X>
>
> Currently domain model has:
>
>     org.hibernate.metamodel.spi.domain.Attribute.getAttributeContainer()
> returning AttributeContainer
>
> I think adding the following would work for Envers:
>
>
> org.hibernate.metamodel.spi.domain.Attribute.getDeclaringAttributeContainer()
> returning AttributeContainer
>
> At least that's what I see so far...
>
> ----- Original Message -----
> > From: "Hardy Ferentschik" <hardy at hibernate.org>
> > To: "Steve Ebersole" <steve at hibernate.org>
> > Cc: "Hibernate" <hibernate-dev at lists.jboss.org>
> > Sent: Tuesday, February 18, 2014 3:34:31 AM
> > Subject: Re: [hibernate-dev] 5.0 metamodel binding
> >
> >
> > On 18 Jan 2014, at 04:28, Steve Ebersole <steve at hibernate.org> wrote:
> >
> > > At the moment all of metamodel binding completely mis-handles
> > > MappedSuperclasses.  The annotation source processor handles them
> somewhat,
> > > but in a very unusable way; it basically flattens all MappedSuperclass
> info
> > > into the nearest Entity.  This is because the source package does not
> at
> > > all support the definition of MappedSuperclass.  And then of course
> > > bindings do nothing with it, since it is not accounted for in source.
> > >
> > > To add this support I plan on the following changes:
> > >
> > > 1) Move lots of the information currently defined by RootEntitySource
> into
> > > EntityHierarchy.  The identifier, version, etc is actually a function
> of
> > > the hierarchy as a whole, so conceptually it makes more sense there
> anyway.
> > > And that mirrors the way we modeled it in the binding spi.
> > > 2) Generalize the EntityHierarchy tree to allow mixing Entity and
> > > MappedSuperclass sources.  A MappedSuperclass source actually needs to
> be
> > > defined.
> > > 3) Model MappedSuperclass in the binding spi as well.
> >
> > +1 especially for #3. The reason the annotations side did this
> flattening was
> > as you say
> > the fact that there was no source equivalent. I think we might have
> discussed
> > this briefly
> > once, but affair back then we decided there was no special need to
> reflecting
> > mapped
> > super class in the source level.
> >
> > ?Hardy
> >
> >
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
>

From steve at hibernate.org  Mon Apr 21 10:48:00 2014
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 21 Apr 2014 09:48:00 -0500
Subject: [hibernate-dev] Jandex, scanning and discovery
Message-ID: <CAFdSV9tMbyjDE5qdAHhBUvTaXNC5W-YSAsvnfr3uXbJRS2UUWA@mail.gmail.com>

As Brett finishes up the "unified schema" work I wanted to start discussion
about some simplifications that could/should come from that.


Jandex, scanning and discovery

One of the outcomes of moving to Jandex to process annotations is the
requirement that we have a good Jandex Index available to us.  There are 2
parts to this:


   1. We need a "baseline Index".  This can be a Jandex Index passed to us
   (by WildFly, e.g.). But in cases where we are not passed one, we need to
   build one.
   2. We then augment the Index with "virtual annotations" built from XML
   mappings.


As I said, in the cases we are not handed a Jandex Index we need to build
one.  Currently this is a tedious process handled by manually indexing all
known classes (known from a few different sources).  But this need to know
the classes to index them is problematic.

Which got me to thinking that it sure would be nice to tie this in to the
scanning (org.hibernate.jpa.boot.scan.spi.Scanner) stuff we do already such
that as we walk the "archive" we automatically add classes we encounter to
the Index.  I'd actually add things to the Index whether or not they are
supposed to be managed classes (exclude-unlisted-classes).

There are lots of benefits to this.  And not just to ORM, provided we start
sharing the Jandex with Search (etc) as we have discussed.  This better
ensures that all needed classes are available in the Index.  This allows
better discovery of "ancillary" classes via annotation.  Etc...

Technically this one is not tied to the unified schema work, we could do
this change today.  The difference is that the move to the unified schema
means that everything is processed using Jandex, so having that good Index
becomes even more important.

There is one difficulty I see here.  Assuming we are to only use
listed-classes, that means classes explicitly listed in the PU *and*
classes listed in XML.  Checking that a class is listed in the PU is
simple, but checking whether a class comes from XML before we use it is not
as straightforward.  Its not impossible, just another thing to consider.


Applying XML defaults

orm.xsd allows specifying attribute specific defaults.  One such default,
e.g., is access.  What happens in the current annotation "mocking"[1] is
that the default access is only applied to attributes that are referenced
in the XML.  If the XML is used in an "override" way and an attribute is
defined in the entity with annotations but is not mentioned in the XML, the
default access from the XML is not picked up, as it should be (unless the
annotations define a more local explicit access).

I think the solution is to expose all the 'persistence-unit-defaults'
values on the org.hibernate.metamodel.source.spi.MappingDefaults and grab
them from there.



-- seems to me there were others I wanted to discuss, but they escape my
mind at the moment ;)


[1] I think we all dislike the term "mocking" here.  I'd like to start
discussing alternatives.  I mentioned "augmentating" above, I like that
one.

From hardy at hibernate.org  Mon Apr 21 15:04:46 2014
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Mon, 21 Apr 2014 21:04:46 +0200
Subject: [hibernate-dev] Jandex, scanning and discovery
In-Reply-To: <CAFdSV9tMbyjDE5qdAHhBUvTaXNC5W-YSAsvnfr3uXbJRS2UUWA@mail.gmail.com>
References: <CAFdSV9tMbyjDE5qdAHhBUvTaXNC5W-YSAsvnfr3uXbJRS2UUWA@mail.gmail.com>
Message-ID: <13900ADC-5394-44A3-AFB7-591F2121E766@hibernate.org>


On 21 Jan 2014, at 16:48, Steve Ebersole <steve at hibernate.org> wrote:

> As Brett finishes up the "unified schema" work I wanted to start discussion
> about some simplifications that could/should come from that.

I really like where all these work is going. I hope the unification will work

> As I said, in the cases we are not handed a Jandex Index we need to build
> one.  Currently this is a tedious process handled by manually indexing all
> known classes (known from a few different sources).  But this need to know
> the classes to index them is problematic.

+1 In this area we had (or maybe still have some failing tests). The old code
used to take used to take the configured classes from the config, build
the hierarchy and process all classes in the hierarchy. So it would for example 
?discover? a @MappedSuperclass even so the class was not explicitly listed 
in the the persistence unit / hibernate config. 

When doing the initial work on Jandex I assumed that all annotated classes 
are in the Jandex index. This, however, requires that all annotated classes would 
need to be explicitly configured. To keep backwards compatibility  we added some
code which would also do the processing of the hierarchy.

> Which got me to thinking that it sure would be nice to tie this in to the
> scanning (org.hibernate.jpa.boot.scan.spi.Scanner) stuff we do already such
> that as we walk the "archive" we automatically add classes we encounter to
> the Index.  I'd actually add things to the Index whether or not they are
> supposed to be managed classes (exclude-unlisted-classes).

+1 Sounds like a good idea and also solves the problem described above in a nice
way.

> There are lots of benefits to this.  And not just to ORM, provided we start
> sharing the Jandex with Search (etc) as we have discussed.

+1 This would be very useful for HSEARCH-1213 where the aim is to switch to Jandex.

>  This better
> ensures that all needed classes are available in the Index.  This allows
> better discovery of "ancillary" classes via annotation.  Etc?

+1

> I think the solution is to expose all the 'persistence-unit-defaults'
> values on the org.hibernate.metamodel.source.spi.MappingDefaults and grab
> them from there.

+1

?Hardy

From steve at hibernate.org  Tue Apr 22 10:05:50 2014
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 22 Apr 2014 09:05:50 -0500
Subject: [hibernate-dev] Meeting time
Message-ID: <CAFdSV9ucR6bFcqMZWuSLmDSEZnKejc2QvKifoLm_6oHQ9fB4LA@mail.gmail.com>

Now that Europe has had its time change, we should be back on for meeting @
10 am US Central TZ I think.

Does that time still works for everyone?

Also, does it make sense to set up the meeting based on a DST-neutral
calendar (so we avoid the different time changes)?

From sanne at hibernate.org  Tue Apr 22 10:19:44 2014
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 22 Apr 2014 15:19:44 +0100
Subject: [hibernate-dev] Meeting time
In-Reply-To: <CAFdSV9ucR6bFcqMZWuSLmDSEZnKejc2QvKifoLm_6oHQ9fB4LA@mail.gmail.com>
References: <CAFdSV9ucR6bFcqMZWuSLmDSEZnKejc2QvKifoLm_6oHQ9fB4LA@mail.gmail.com>
Message-ID: <CAFm4XO2Yx=iWRWmfrvpNhknP2PuNXuQmG3BBreeubf7RPWNiag@mail.gmail.com>

On 22 April 2014 15:05, Steve Ebersole <steve at hibernate.org> wrote:
> Now that Europe has had its time change, we should be back on for meeting @
> 10 am US Central TZ I think.
>
> Does that time still works for everyone?

+1

> Also, does it make sense to set up the meeting based on a DST-neutral
> calendar (so we avoid the different time changes)?

I like the idea, but is that an option supported in calendaring
software? I just looked in google-calendar and I could only find a
timezone based on a country/City.. is there any City in the world
which banned DST?

From steve at hibernate.org  Tue Apr 22 10:34:07 2014
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 22 Apr 2014 09:34:07 -0500
Subject: [hibernate-dev] Meeting time
In-Reply-To: <CAFm4XO2Yx=iWRWmfrvpNhknP2PuNXuQmG3BBreeubf7RPWNiag@mail.gmail.com>
References: <CAFdSV9ucR6bFcqMZWuSLmDSEZnKejc2QvKifoLm_6oHQ9fB4LA@mail.gmail.com>
	<CAFm4XO2Yx=iWRWmfrvpNhknP2PuNXuQmG3BBreeubf7RPWNiag@mail.gmail.com>
Message-ID: <CAFdSV9v55XHb9QrkN+rXAP=LY-mcwah7feGgdGo5+yrDOeLpSA@mail.gmail.com>

Tucsan AZ in the US does not recognize DST :
http://www.timeanddate.com/time/us/arizona-no-dst.html


On Tue, Apr 22, 2014 at 9:19 AM, Sanne Grinovero <sanne at hibernate.org>wrote:

> On 22 April 2014 15:05, Steve Ebersole <steve at hibernate.org> wrote:
> > Now that Europe has had its time change, we should be back on for
> meeting @
> > 10 am US Central TZ I think.
> >
> > Does that time still works for everyone?
>
> +1
>
> > Also, does it make sense to set up the meeting based on a DST-neutral
> > calendar (so we avoid the different time changes)?
>
> I like the idea, but is that an option supported in calendaring
> software? I just looked in google-calendar and I could only find a
> timezone based on a country/City.. is there any City in the world
> which banned DST?
>

From steve at hibernate.org  Tue Apr 22 10:37:23 2014
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 22 Apr 2014 09:37:23 -0500
Subject: [hibernate-dev] Meeting time
In-Reply-To: <CAFdSV9v55XHb9QrkN+rXAP=LY-mcwah7feGgdGo5+yrDOeLpSA@mail.gmail.com>
References: <CAFdSV9ucR6bFcqMZWuSLmDSEZnKejc2QvKifoLm_6oHQ9fB4LA@mail.gmail.com>
	<CAFm4XO2Yx=iWRWmfrvpNhknP2PuNXuQmG3BBreeubf7RPWNiag@mail.gmail.com>
	<CAFdSV9v55XHb9QrkN+rXAP=LY-mcwah7feGgdGo5+yrDOeLpSA@mail.gmail.com>
Message-ID: <CAFdSV9vp4tvgZLjNofS8eA82mjmK7v5uW_uZiX71dqt4joT9mw@mail.gmail.com>

Is "UTC" subject to DST?


On Tue, Apr 22, 2014 at 9:34 AM, Steve Ebersole <steve at hibernate.org> wrote:

> Tucsan AZ in the US does not recognize DST :
> http://www.timeanddate.com/time/us/arizona-no-dst.html
>
>
> On Tue, Apr 22, 2014 at 9:19 AM, Sanne Grinovero <sanne at hibernate.org>wrote:
>
>> On 22 April 2014 15:05, Steve Ebersole <steve at hibernate.org> wrote:
>> > Now that Europe has had its time change, we should be back on for
>> meeting @
>> > 10 am US Central TZ I think.
>> >
>> > Does that time still works for everyone?
>>
>> +1
>>
>> > Also, does it make sense to set up the meeting based on a DST-neutral
>> > calendar (so we avoid the different time changes)?
>>
>> I like the idea, but is that an option supported in calendaring
>> software? I just looked in google-calendar and I could only find a
>> timezone based on a country/City.. is there any City in the world
>> which banned DST?
>>
>
>

From sanne at hibernate.org  Tue Apr 22 10:42:29 2014
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 22 Apr 2014 15:42:29 +0100
Subject: [hibernate-dev] Meeting time
In-Reply-To: <CAFdSV9vp4tvgZLjNofS8eA82mjmK7v5uW_uZiX71dqt4joT9mw@mail.gmail.com>
References: <CAFdSV9ucR6bFcqMZWuSLmDSEZnKejc2QvKifoLm_6oHQ9fB4LA@mail.gmail.com>
	<CAFm4XO2Yx=iWRWmfrvpNhknP2PuNXuQmG3BBreeubf7RPWNiag@mail.gmail.com>
	<CAFdSV9v55XHb9QrkN+rXAP=LY-mcwah7feGgdGo5+yrDOeLpSA@mail.gmail.com>
	<CAFdSV9vp4tvgZLjNofS8eA82mjmK7v5uW_uZiX71dqt4joT9mw@mail.gmail.com>
Message-ID: <CAFm4XO2QTkLdM2xbOW+cTHkkXFQK5fp+-T5j1Wnt64cj7tS_uA@mail.gmail.com>

On 22 April 2014 15:37, Steve Ebersole <steve at hibernate.org> wrote:
> Is "UTC" subject to DST?

No, good point. Let's use UTC?

>
>
> On Tue, Apr 22, 2014 at 9:34 AM, Steve Ebersole <steve at hibernate.org> wrote:
>>
>> Tucsan AZ in the US does not recognize DST :
>> http://www.timeanddate.com/time/us/arizona-no-dst.html
>>
>>
>> On Tue, Apr 22, 2014 at 9:19 AM, Sanne Grinovero <sanne at hibernate.org>
>> wrote:
>>>
>>> On 22 April 2014 15:05, Steve Ebersole <steve at hibernate.org> wrote:
>>> > Now that Europe has had its time change, we should be back on for
>>> > meeting @
>>> > 10 am US Central TZ I think.
>>> >
>>> > Does that time still works for everyone?
>>>
>>> +1
>>>
>>> > Also, does it make sense to set up the meeting based on a DST-neutral
>>> > calendar (so we avoid the different time changes)?
>>>
>>> I like the idea, but is that an option supported in calendaring
>>> software? I just looked in google-calendar and I could only find a
>>> timezone based on a country/City.. is there any City in the world
>>> which banned DST?
>>
>>
>

From brmeyer at redhat.com  Tue Apr 22 10:45:42 2014
From: brmeyer at redhat.com (Brett Meyer)
Date: Tue, 22 Apr 2014 10:45:42 -0400 (EDT)
Subject: [hibernate-dev] Meeting time
In-Reply-To: <CAFm4XO2QTkLdM2xbOW+cTHkkXFQK5fp+-T5j1Wnt64cj7tS_uA@mail.gmail.com>
References: <CAFdSV9ucR6bFcqMZWuSLmDSEZnKejc2QvKifoLm_6oHQ9fB4LA@mail.gmail.com>
	<CAFm4XO2Yx=iWRWmfrvpNhknP2PuNXuQmG3BBreeubf7RPWNiag@mail.gmail.com>
	<CAFdSV9v55XHb9QrkN+rXAP=LY-mcwah7feGgdGo5+yrDOeLpSA@mail.gmail.com>
	<CAFdSV9vp4tvgZLjNofS8eA82mjmK7v5uW_uZiX71dqt4joT9mw@mail.gmail.com>
	<CAFm4XO2QTkLdM2xbOW+cTHkkXFQK5fp+-T5j1Wnt64cj7tS_uA@mail.gmail.com>
Message-ID: <423719448.8786292.1398177942340.JavaMail.zimbra@redhat.com>

Relevant: "The Problem with Time & Timezones - Computerphile"
https://www.youtube.com/watch?v=-5wpm-gesOY

;)

----- Original Message -----
From: "Sanne Grinovero" <sanne at hibernate.org>
To: "Steve Ebersole" <steve at hibernate.org>
Cc: "hibernate-dev" <hibernate-dev at lists.jboss.org>
Sent: Tuesday, April 22, 2014 10:42:29 AM
Subject: Re: [hibernate-dev] Meeting time

On 22 April 2014 15:37, Steve Ebersole <steve at hibernate.org> wrote:
> Is "UTC" subject to DST?

No, good point. Let's use UTC?

>
>
> On Tue, Apr 22, 2014 at 9:34 AM, Steve Ebersole <steve at hibernate.org> wrote:
>>
>> Tucsan AZ in the US does not recognize DST :
>> http://www.timeanddate.com/time/us/arizona-no-dst.html
>>
>>
>> On Tue, Apr 22, 2014 at 9:19 AM, Sanne Grinovero <sanne at hibernate.org>
>> wrote:
>>>
>>> On 22 April 2014 15:05, Steve Ebersole <steve at hibernate.org> wrote:
>>> > Now that Europe has had its time change, we should be back on for
>>> > meeting @
>>> > 10 am US Central TZ I think.
>>> >
>>> > Does that time still works for everyone?
>>>
>>> +1
>>>
>>> > Also, does it make sense to set up the meeting based on a DST-neutral
>>> > calendar (so we avoid the different time changes)?
>>>
>>> I like the idea, but is that an option supported in calendaring
>>> software? I just looked in google-calendar and I could only find a
>>> timezone based on a country/City.. is there any City in the world
>>> which banned DST?
>>
>>
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

From gunnar at hibernate.org  Tue Apr 22 10:55:55 2014
From: gunnar at hibernate.org (Gunnar Morling)
Date: Tue, 22 Apr 2014 16:55:55 +0200
Subject: [hibernate-dev] Meeting time
In-Reply-To: <CAFm4XO2QTkLdM2xbOW+cTHkkXFQK5fp+-T5j1Wnt64cj7tS_uA@mail.gmail.com>
References: <CAFdSV9ucR6bFcqMZWuSLmDSEZnKejc2QvKifoLm_6oHQ9fB4LA@mail.gmail.com>
	<CAFm4XO2Yx=iWRWmfrvpNhknP2PuNXuQmG3BBreeubf7RPWNiag@mail.gmail.com>
	<CAFdSV9v55XHb9QrkN+rXAP=LY-mcwah7feGgdGo5+yrDOeLpSA@mail.gmail.com>
	<CAFdSV9vp4tvgZLjNofS8eA82mjmK7v5uW_uZiX71dqt4joT9mw@mail.gmail.com>
	<CAFm4XO2QTkLdM2xbOW+cTHkkXFQK5fp+-T5j1Wnt64cj7tS_uA@mail.gmail.com>
Message-ID: <CADGJaX85ForsFqRc0BAvT71s4j=Jti1tDYQAMW4g+u9Y8RYQBg@mail.gmail.com>

Using UTC is not a bad idea.

I like using timeanddate.com to plan meetings (see [1] for an example). You
add the cities of participants, get a time table with UTC and all involved
local times and can send a link such as [2] to the participants.

--Gunnar


[1]
http://www.timeanddate.com/worldclock/meetingtime.html?iso=20140422&p1=307&p2=24&p3=136&p4=234
[2]
http://www.timeanddate.com/worldclock/meetingdetails.html?year=2014&month=4&day=22&hour=15&min=0&sec=0&p1=307&p2=24&p3=136&p4=234


2014-04-22 16:42 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:

> On 22 April 2014 15:37, Steve Ebersole <steve at hibernate.org> wrote:
> > Is "UTC" subject to DST?
>
> No, good point. Let's use UTC?
>
> >
> >
> > On Tue, Apr 22, 2014 at 9:34 AM, Steve Ebersole <steve at hibernate.org>
> wrote:
> >>
> >> Tucsan AZ in the US does not recognize DST :
> >> http://www.timeanddate.com/time/us/arizona-no-dst.html
> >>
> >>
> >> On Tue, Apr 22, 2014 at 9:19 AM, Sanne Grinovero <sanne at hibernate.org>
> >> wrote:
> >>>
> >>> On 22 April 2014 15:05, Steve Ebersole <steve at hibernate.org> wrote:
> >>> > Now that Europe has had its time change, we should be back on for
> >>> > meeting @
> >>> > 10 am US Central TZ I think.
> >>> >
> >>> > Does that time still works for everyone?
> >>>
> >>> +1
> >>>
> >>> > Also, does it make sense to set up the meeting based on a DST-neutral
> >>> > calendar (so we avoid the different time changes)?
> >>>
> >>> I like the idea, but is that an option supported in calendaring
> >>> software? I just looked in google-calendar and I could only find a
> >>> timezone based on a country/City.. is there any City in the world
> >>> which banned DST?
> >>
> >>
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Tue Apr 22 10:58:56 2014
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 22 Apr 2014 09:58:56 -0500
Subject: [hibernate-dev] Meeting time
In-Reply-To: <CADGJaX85ForsFqRc0BAvT71s4j=Jti1tDYQAMW4g+u9Y8RYQBg@mail.gmail.com>
References: <CAFdSV9ucR6bFcqMZWuSLmDSEZnKejc2QvKifoLm_6oHQ9fB4LA@mail.gmail.com>
	<CAFm4XO2Yx=iWRWmfrvpNhknP2PuNXuQmG3BBreeubf7RPWNiag@mail.gmail.com>
	<CAFdSV9v55XHb9QrkN+rXAP=LY-mcwah7feGgdGo5+yrDOeLpSA@mail.gmail.com>
	<CAFdSV9vp4tvgZLjNofS8eA82mjmK7v5uW_uZiX71dqt4joT9mw@mail.gmail.com>
	<CAFm4XO2QTkLdM2xbOW+cTHkkXFQK5fp+-T5j1Wnt64cj7tS_uA@mail.gmail.com>
	<CADGJaX85ForsFqRc0BAvT71s4j=Jti1tDYQAMW4g+u9Y8RYQBg@mail.gmail.com>
Message-ID: <CAFdSV9tnfC1oYJEQNTcFR-cXgzyKY=qs+4jv2QCYcMf8pBTUcQ@mail.gmail.com>

That would be great if it weren't date specific.  I'd love to drop a link
for this on the website, but that would need to be date-agnostic


On Tue, Apr 22, 2014 at 9:55 AM, Gunnar Morling <gunnar at hibernate.org>wrote:

> Using UTC is not a bad idea.
>
> I like using timeanddate.com to plan meetings (see [1] for an example).
> You add the cities of participants, get a time table with UTC and all
> involved local times and can send a link such as [2] to the participants.
>
> --Gunnar
>
>
> [1]
> http://www.timeanddate.com/worldclock/meetingtime.html?iso=20140422&p1=307&p2=24&p3=136&p4=234
> [2]
> http://www.timeanddate.com/worldclock/meetingdetails.html?year=2014&month=4&day=22&hour=15&min=0&sec=0&p1=307&p2=24&p3=136&p4=234
>
>
> 2014-04-22 16:42 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
>
>> On 22 April 2014 15:37, Steve Ebersole <steve at hibernate.org> wrote:
>> > Is "UTC" subject to DST?
>>
>> No, good point. Let's use UTC?
>>
>> >
>> >
>> > On Tue, Apr 22, 2014 at 9:34 AM, Steve Ebersole <steve at hibernate.org>
>> wrote:
>> >>
>> >> Tucsan AZ in the US does not recognize DST :
>> >> http://www.timeanddate.com/time/us/arizona-no-dst.html
>> >>
>> >>
>> >> On Tue, Apr 22, 2014 at 9:19 AM, Sanne Grinovero <sanne at hibernate.org>
>> >> wrote:
>> >>>
>> >>> On 22 April 2014 15:05, Steve Ebersole <steve at hibernate.org> wrote:
>> >>> > Now that Europe has had its time change, we should be back on for
>> >>> > meeting @
>> >>> > 10 am US Central TZ I think.
>> >>> >
>> >>> > Does that time still works for everyone?
>> >>>
>> >>> +1
>> >>>
>> >>> > Also, does it make sense to set up the meeting based on a
>> DST-neutral
>> >>> > calendar (so we avoid the different time changes)?
>> >>>
>> >>> I like the idea, but is that an option supported in calendaring
>> >>> software? I just looked in google-calendar and I could only find a
>> >>> timezone based on a country/City.. is there any City in the world
>> >>> which banned DST?
>> >>
>> >>
>> >
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>

From gunnar at hibernate.org  Wed Apr 23 05:18:32 2014
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 23 Apr 2014 11:18:32 +0200
Subject: [hibernate-dev] [OGM] Pull request job issues fixed
Message-ID: <CADGJaX95dm5KuqU01Fbf_Kq+P0Jk6ZRkJdR-es4k+0XnBdCjPQ@mail.gmail.com>

Hi,

The OGM pull request job is fine again now.

The issue was that I had configured it to use a private M2 repo (to avoid
conflicts with the master job) within the workspace which then ended up
being added to the distribution TAR which failed due to size constraints.
The repo lives at another place now to avoid this.

--Gunnar

From steve at hibernate.org  Thu Apr 24 17:25:39 2014
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 24 Apr 2014 16:25:39 -0500
Subject: [hibernate-dev] Jandex, scanning and discovery
In-Reply-To: <13900ADC-5394-44A3-AFB7-591F2121E766@hibernate.org>
References: <CAFdSV9tMbyjDE5qdAHhBUvTaXNC5W-YSAsvnfr3uXbJRS2UUWA@mail.gmail.com>
	<13900ADC-5394-44A3-AFB7-591F2121E766@hibernate.org>
Message-ID: <CAFdSV9uwPrc4Oa0UGjOus9C3Pe71Av_dDB=2SXu2zFNAve_hoA@mail.gmail.com>

I have this working, but given the current scope of Scanner it is
unfortunately of limited use.  That is, currently it only works when using
JPA boostrapping (technically, whenever you use the
EntityManagerFactoryBuilder).

Given how central we are making Jandex in this scheme, I think its
worthwhile to consider ways to make it work in "native Hibernate"
bootstrapping as well.  Maybe this is as simple as allowing the user to
specify a base url for scanning.

I'd like to suggest one change in scanning to support this as well.
 Currently when the Scanner finds a Class, or package-info, etc it
immediately checks the "options" to see if this entry can be accepted
(essentially according to the PU).  I'd rather change this up so that the
collector is notified as soon as we find an entry.  This would allow the
collector to index the entry in Jandex no matter what and to decide what
else to do with it (add it list of managed classes, etc).

WDYT?



On Mon, Apr 21, 2014 at 2:04 PM, Hardy Ferentschik <hardy at hibernate.org>wrote:

>
> On 21 Jan 2014, at 16:48, Steve Ebersole <steve at hibernate.org> wrote:
>
> > As Brett finishes up the "unified schema" work I wanted to start
> discussion
> > about some simplifications that could/should come from that.
>
> I really like where all these work is going. I hope the unification will
> work
>
> > As I said, in the cases we are not handed a Jandex Index we need to build
> > one.  Currently this is a tedious process handled by manually indexing
> all
> > known classes (known from a few different sources).  But this need to
> know
> > the classes to index them is problematic.
>
> +1 In this area we had (or maybe still have some failing tests). The old
> code
> used to take used to take the configured classes from the config, build
> the hierarchy and process all classes in the hierarchy. So it would for
> example
> ?discover? a @MappedSuperclass even so the class was not explicitly listed
> in the the persistence unit / hibernate config.
>
> When doing the initial work on Jandex I assumed that all annotated classes
> are in the Jandex index. This, however, requires that all annotated
> classes would
> need to be explicitly configured. To keep backwards compatibility  we
> added some
> code which would also do the processing of the hierarchy.
>
> > Which got me to thinking that it sure would be nice to tie this in to the
> > scanning (org.hibernate.jpa.boot.scan.spi.Scanner) stuff we do already
> such
> > that as we walk the "archive" we automatically add classes we encounter
> to
> > the Index.  I'd actually add things to the Index whether or not they are
> > supposed to be managed classes (exclude-unlisted-classes).
>
> +1 Sounds like a good idea and also solves the problem described above in
> a nice
> way.
>
> > There are lots of benefits to this.  And not just to ORM, provided we
> start
> > sharing the Jandex with Search (etc) as we have discussed.
>
> +1 This would be very useful for HSEARCH-1213 where the aim is to switch
> to Jandex.
>
> >  This better
> > ensures that all needed classes are available in the Index.  This allows
> > better discovery of "ancillary" classes via annotation.  Etc?
>
> +1
>
> > I think the solution is to expose all the 'persistence-unit-defaults'
> > values on the org.hibernate.metamodel.source.spi.MappingDefaults and grab
> > them from there.
>
> +1
>
> ?Hardy

From hardy at hibernate.org  Thu Apr 24 17:34:41 2014
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Thu, 24 Apr 2014 23:34:41 +0200
Subject: [hibernate-dev] Jandex, scanning and discovery
In-Reply-To: <CAFdSV9uwPrc4Oa0UGjOus9C3Pe71Av_dDB=2SXu2zFNAve_hoA@mail.gmail.com>
References: <CAFdSV9tMbyjDE5qdAHhBUvTaXNC5W-YSAsvnfr3uXbJRS2UUWA@mail.gmail.com>
	<13900ADC-5394-44A3-AFB7-591F2121E766@hibernate.org>
	<CAFdSV9uwPrc4Oa0UGjOus9C3Pe71Av_dDB=2SXu2zFNAve_hoA@mail.gmail.com>
Message-ID: <901F31BB-98CC-4704-8B38-DF633A62030C@hibernate.org>


On 24 Jan 2014, at 23:25, Steve Ebersole <steve at hibernate.org> wrote:

> I'd like to suggest one change in scanning to support this as well.  Currently when the Scanner finds a Class, or package-info, etc it immediately checks the "options" to see if this entry can be accepted (essentially according to the PU).  I'd rather change this up so that the collector is notified as soon as we find an entry.  This would allow the collector to index the entry in Jandex no matter what and to decide what else to do with it (add it list of managed classes, etc).

+1, as you say, I think we get more benefit out of the Jandex index if we index all entries/classes.

?Hardy



From gunnar at hibernate.org  Fri Apr 25 04:41:17 2014
From: gunnar at hibernate.org (Gunnar Morling)
Date: Fri, 25 Apr 2014 10:41:17 +0200
Subject: [hibernate-dev] Making tests nicer with lambdas
Message-ID: <CADGJaX9mdvtNGCdcKgGOzwzNV4jQ4hL6BH9mKvRjD5F2aK8hAg@mail.gmail.com>

Hey,

I've played around a bit with the idea of using Java 8 lambdas to make
tests easier to write and read. We have many tests which open a session and
TX, do some stuff, commit, open a new TX (and/or session), do some
assertions and so on:

    Session session = openSession();
  Transaction transaction = session.beginTransaction();

    // heavy testing action...
    transaction.commit();
  session.clear();

    transaction = session.beginTransaction();

    // load, assert...
  transaction.commit();
  session.clear();

The same could look like this using Java 8 lambdas:

    Foo foo = inTransactionWithResult( (session, tx) -> {
        // heavy testing action...
  } );

    inTransaction( (session, tx) -> {
        // load, assert...
  } );

Extracting the session/TX handling removes quite some clutter and focuses
more on the actual testing logic. It also avoids problems due to dangling
transactions e.g. in case of assertion failures as the TX handling is done
in a finally block in inTransaction().

At this point I've just done a quick POC and would be interested in
feedback whether you think that's worth pursuing or not. Note that
different language levels can be used for test and main code, so we could
make use of lambdas in tests while ensuring Java 6 compatibility for the
delivered artifacts.

--Gunnar

From hardy at hibernate.org  Fri Apr 25 06:57:51 2014
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Fri, 25 Apr 2014 12:57:51 +0200
Subject: [hibernate-dev] Making tests nicer with lambdas
In-Reply-To: <CADGJaX9mdvtNGCdcKgGOzwzNV4jQ4hL6BH9mKvRjD5F2aK8hAg@mail.gmail.com>
References: <CADGJaX9mdvtNGCdcKgGOzwzNV4jQ4hL6BH9mKvRjD5F2aK8hAg@mail.gmail.com>
Message-ID: <DEC26880-8F21-4CF3-9B0C-9C66A3E92093@hibernate.org>


On 25 Jan 2014, at 10:41, Gunnar Morling <gunnar at hibernate.org> wrote:

> I've played around a bit with the idea of using Java 8 lambdas to make
> tests easier to write and read. We have many tests which open a session and
> TX, do some stuff, commit, open a new TX (and/or session), do some
> assertions and so on:
> 
>    Session session = openSession();
>  Transaction transaction = session.beginTransaction();
> 
>    // heavy testing action...
>    transaction.commit();
>  session.clear();
> 
>    transaction = session.beginTransaction();
> 
>    // load, assert...
>  transaction.commit();
>  session.clear();
> 
> The same could look like this using Java 8 lambdas:
> 
>    Foo foo = inTransactionWithResult( (session, tx) -> {
>        // heavy testing action...
>  } );
> 
>    inTransaction( (session, tx) -> {
>        // load, assert...
>  } );
> 
> Extracting the session/TX handling removes quite some clutter and focuses
> more on the actual testing logic.

Makes things a but nicer. A bit of syntactic sugger. Not sure though whether it is enough to
switch to JDK 8 for building.

> It also avoids problems due to dangling
> transactions e.g. in case of assertion failures as the TX handling is done
> in a finally block in inTransaction().

A lot of this should already be taken care of by the CustomRunner we use to execute the tests.

?Hardy

From steve at hibernate.org  Fri Apr 25 12:57:48 2014
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 25 Apr 2014 11:57:48 -0500
Subject: [hibernate-dev] Jandex, scanning and discovery
In-Reply-To: <901F31BB-98CC-4704-8B38-DF633A62030C@hibernate.org>
References: <CAFdSV9tMbyjDE5qdAHhBUvTaXNC5W-YSAsvnfr3uXbJRS2UUWA@mail.gmail.com>
	<13900ADC-5394-44A3-AFB7-591F2121E766@hibernate.org>
	<CAFdSV9uwPrc4Oa0UGjOus9C3Pe71Av_dDB=2SXu2zFNAve_hoA@mail.gmail.com>
	<901F31BB-98CC-4704-8B38-DF633A62030C@hibernate.org>
Message-ID: <CAFdSV9uYjXNScDk_Pz67gmqPoZkBF7_q=w7y9B7bmSAMZta3bA@mail.gmail.com>

So here is what I propose more concretely...

As a refresher, there are a few main characters:
* Scanner - coordinates the scanning effort
* PersistenceUnitDescriptor - provides access to needed PU information
* ScanOptions - a few booleans to control processing within Scanner
* ArchiveDescriptorFactory - essentially acts as a "URL interpreter" (this
is one of the main customization points in the new scanning code)
* ArchiveDescriptor / ArchiveEntry - describe the parts of the archive we
want to look at
* ArchiveEntryHandler - the main visitation contract for inspecting
ArchiveEntry

ArchiveEntryHandler is the place where the collection happens.  There are
ArchiveEntryHandler specializations for each type of archive entry: class
file, package-info file, etc.  The ArchiveEntryHandler for class files is
really the only place that needs a change (to add to a supplied Jandex
Indexer).  However, I think some other changes are worthwhile.  First,
relying on PersistenceUnitDescriptor ties this to building of an EMF.  With
a simple tweak, we could make this usable in "native SF" building also.
 And given the above stated importance on Jandex, I think this is
worthwhile change.

I wanted to go over the specifics because this is an SPI, and because I
know at least one customization of this SPI for integration : WildFly,
which hooks in mainly to deal with its VFS URL handling.  I think WildFly
usage should be safe from these changes.



On Thu, Apr 24, 2014 at 4:34 PM, Hardy Ferentschik <hardy at hibernate.org>wrote:

>
> On 24 Jan 2014, at 23:25, Steve Ebersole <steve at hibernate.org> wrote:
>
> > I'd like to suggest one change in scanning to support this as well.
>  Currently when the Scanner finds a Class, or package-info, etc it
> immediately checks the "options" to see if this entry can be accepted
> (essentially according to the PU).  I'd rather change this up so that the
> collector is notified as soon as we find an entry.  This would allow the
> collector to index the entry in Jandex no matter what and to decide what
> else to do with it (add it list of managed classes, etc).
>
> +1, as you say, I think we get more benefit out of the Jandex index if we
> index all entries/classes.
>
> ?Hardy
>
>

From sanne at hibernate.org  Sat Apr 26 18:42:46 2014
From: sanne at hibernate.org (Sanne Grinovero)
Date: Sat, 26 Apr 2014 23:42:46 +0100
Subject: [hibernate-dev] Making tests nicer with lambdas
In-Reply-To: <CADGJaX9mdvtNGCdcKgGOzwzNV4jQ4hL6BH9mKvRjD5F2aK8hAg@mail.gmail.com>
References: <CADGJaX9mdvtNGCdcKgGOzwzNV4jQ4hL6BH9mKvRjD5F2aK8hAg@mail.gmail.com>
Message-ID: <CAFm4XO3FF36xoqfEkDOSsymTHsRDdaYbfV6Y_orpuuBXvwaXMA@mail.gmail.com>

I love the idea, but I'm coming from a very different angle:
it's important that we regularly exercise our APIs, and verify that
they make sense in the new world.

But can we reliably run tests compiled with Java8 but still verify our
main library is going to run fine in previous JVMs?

I don't fully trust things like animal-sniffer, I want to actually run
our stuff on older VMs.

Sanne

On 25 April 2014 09:41, Gunnar Morling <gunnar at hibernate.org> wrote:
> Hey,
>
> I've played around a bit with the idea of using Java 8 lambdas to make
> tests easier to write and read. We have many tests which open a session and
> TX, do some stuff, commit, open a new TX (and/or session), do some
> assertions and so on:
>
>     Session session = openSession();
>   Transaction transaction = session.beginTransaction();
>
>     // heavy testing action...
>     transaction.commit();
>   session.clear();
>
>     transaction = session.beginTransaction();
>
>     // load, assert...
>   transaction.commit();
>   session.clear();
>
> The same could look like this using Java 8 lambdas:
>
>     Foo foo = inTransactionWithResult( (session, tx) -> {
>         // heavy testing action...
>   } );
>
>     inTransaction( (session, tx) -> {
>         // load, assert...
>   } );
>
> Extracting the session/TX handling removes quite some clutter and focuses
> more on the actual testing logic. It also avoids problems due to dangling
> transactions e.g. in case of assertion failures as the TX handling is done
> in a finally block in inTransaction().
>
> At this point I've just done a quick POC and would be interested in
> feedback whether you think that's worth pursuing or not. Note that
> different language levels can be used for test and main code, so we could
> make use of lambdas in tests while ensuring Java 6 compatibility for the
> delivered artifacts.
>
> --Gunnar
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From gunnar at hibernate.org  Mon Apr 28 10:49:19 2014
From: gunnar at hibernate.org (Gunnar Morling)
Date: Mon, 28 Apr 2014 16:49:19 +0200
Subject: [hibernate-dev] GitHub repo for demo projects
Message-ID: <CADGJaX9P_CikxL8xLBqW1eBYTnYtrunymHL3KjheWJxxbu-g0A@mail.gmail.com>

Hi,

Together with Sanne I've been creating a demo app which shows some features
of Hibernate OGM.

Right now this lives under my personal account on GitHub, but IMO it'd make
sense to move it somewhere under https://github.com/hibernate/ to make it
more visible, encourage re-use and contributions by others etc.

What do you think about creating a repo under the hibernate organization
such as "hibernate-demos" which could host this and other demos for our
projects in the future? Or would it even make more sense on a per-project
base ("hibernate-ogm-demos" etc.)?

--Gunnar

[1] https://github.com/gunnarmorling/ogm-hiking-demo

From brmeyer at redhat.com  Mon Apr 28 11:03:50 2014
From: brmeyer at redhat.com (Brett Meyer)
Date: Mon, 28 Apr 2014 11:03:50 -0400 (EDT)
Subject: [hibernate-dev] GitHub repo for demo projects
In-Reply-To: <CADGJaX9P_CikxL8xLBqW1eBYTnYtrunymHL3KjheWJxxbu-g0A@mail.gmail.com>
References: <CADGJaX9P_CikxL8xLBqW1eBYTnYtrunymHL3KjheWJxxbu-g0A@mail.gmail.com>
Message-ID: <433255762.13249435.1398697430255.JavaMail.zimbra@redhat.com>

+1 from me.  I have several to contribute as well from various ORM presentations.

https://github.com/brmeyer/HibernateDemos

----- Original Message -----
From: "Gunnar Morling" <gunnar at hibernate.org>
To: hibernate-dev at lists.jboss.org
Sent: Monday, April 28, 2014 10:49:19 AM
Subject: [hibernate-dev] GitHub repo for demo projects

Hi,

Together with Sanne I've been creating a demo app which shows some features
of Hibernate OGM.

Right now this lives under my personal account on GitHub, but IMO it'd make
sense to move it somewhere under https://github.com/hibernate/ to make it
more visible, encourage re-use and contributions by others etc.

What do you think about creating a repo under the hibernate organization
such as "hibernate-demos" which could host this and other demos for our
projects in the future? Or would it even make more sense on a per-project
base ("hibernate-ogm-demos" etc.)?

--Gunnar

[1] https://github.com/gunnarmorling/ogm-hiking-demo
_______________________________________________
hibernate-dev mailing list
hibernate-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

From steve at hibernate.org  Mon Apr 28 11:20:31 2014
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 28 Apr 2014 10:20:31 -0500
Subject: [hibernate-dev] Jandex, scanning and discovery
In-Reply-To: <CAFdSV9uYjXNScDk_Pz67gmqPoZkBF7_q=w7y9B7bmSAMZta3bA@mail.gmail.com>
References: <CAFdSV9tMbyjDE5qdAHhBUvTaXNC5W-YSAsvnfr3uXbJRS2UUWA@mail.gmail.com>
	<13900ADC-5394-44A3-AFB7-591F2121E766@hibernate.org>
	<CAFdSV9uwPrc4Oa0UGjOus9C3Pe71Av_dDB=2SXu2zFNAve_hoA@mail.gmail.com>
	<901F31BB-98CC-4704-8B38-DF633A62030C@hibernate.org>
	<CAFdSV9uYjXNScDk_Pz67gmqPoZkBF7_q=w7y9B7bmSAMZta3bA@mail.gmail.com>
Message-ID: <CAFdSV9sjvGvifJkU+Bpk7QPpHpvR65zJBJC0d3XbE87Lqx6zuQ@mail.gmail.com>

Almost done with this.  We are much more aggressive about indexing stuff
into Jandex now (which is a good thing) when we are not handed a Jandex
Index.

However, this does mean we need to be more careful in the case of JPA and
exclude-non-listed-classes.  ATM we drive annotations based on Jandex (aka,
the classes known to Jandex).  However, if we know index classes that
should not be used as entities, etc (because of exclude-non-listed-classes)
we are breaking the JPA spec.  To this end, I suggest that scanning:
1) Index everything
2) Keep a running tab of "allowable managed classes and packages".

Later, when beginning interpretation of annotations (via Jandex) we can
cross-reference that with the list of allowable managed classes.  Currently
we do:

for ( ClassInfo classInfo :
bindingContext.getJandexAccess().getIndex().getKnownClasses() ) {
    // use them all...
}


What I am suggesting is:

interface ManagedClassFilter {
    public boolean allowAsManagedClass(ClassInfo classInfo);
}

for ( ClassInfo classInfo :
bindingContext.getJandexAccess().getIndex().getKnownClasses() ) {
    if ( !managedClassFiler.allowAsManagedClass( classInfo ) ) {
        continue;
    }
}

Further, rather than maintaining potentially large lists of allowable class
and package names, I'd also suggest we recognize the cases when we have
open-ended discovery in play and simply use an "all inclusive" strategy.




On Fri, Apr 25, 2014 at 11:57 AM, Steve Ebersole <steve at hibernate.org>wrote:

> So here is what I propose more concretely...
>
> As a refresher, there are a few main characters:
> * Scanner - coordinates the scanning effort
> * PersistenceUnitDescriptor - provides access to needed PU information
> * ScanOptions - a few booleans to control processing within Scanner
> * ArchiveDescriptorFactory - essentially acts as a "URL interpreter" (this
> is one of the main customization points in the new scanning code)
> * ArchiveDescriptor / ArchiveEntry - describe the parts of the archive we
> want to look at
> * ArchiveEntryHandler - the main visitation contract for inspecting
> ArchiveEntry
>
> ArchiveEntryHandler is the place where the collection happens.  There are
> ArchiveEntryHandler specializations for each type of archive entry: class
> file, package-info file, etc.  The ArchiveEntryHandler for class files is
> really the only place that needs a change (to add to a supplied Jandex
> Indexer).  However, I think some other changes are worthwhile.  First,
> relying on PersistenceUnitDescriptor ties this to building of an EMF.  With
> a simple tweak, we could make this usable in "native SF" building also.
>  And given the above stated importance on Jandex, I think this is
> worthwhile change.
>
> I wanted to go over the specifics because this is an SPI, and because I
> know at least one customization of this SPI for integration : WildFly,
> which hooks in mainly to deal with its VFS URL handling.  I think WildFly
> usage should be safe from these changes.
>
>
>
> On Thu, Apr 24, 2014 at 4:34 PM, Hardy Ferentschik <hardy at hibernate.org>wrote:
>
>>
>> On 24 Jan 2014, at 23:25, Steve Ebersole <steve at hibernate.org> wrote:
>>
>> > I'd like to suggest one change in scanning to support this as well.
>>  Currently when the Scanner finds a Class, or package-info, etc it
>> immediately checks the "options" to see if this entry can be accepted
>> (essentially according to the PU).  I'd rather change this up so that the
>> collector is notified as soon as we find an entry.  This would allow the
>> collector to index the entry in Jandex no matter what and to decide what
>> else to do with it (add it list of managed classes, etc).
>>
>> +1, as you say, I think we get more benefit out of the Jandex index if we
>> index all entries/classes.
>>
>> ?Hardy
>>
>>
>

From daltodavide at gmail.com  Mon Apr 28 11:28:54 2014
From: daltodavide at gmail.com (Davide D'Alto)
Date: Mon, 28 Apr 2014 16:28:54 +0100
Subject: [hibernate-dev] GitHub repo for demo projects
In-Reply-To: <433255762.13249435.1398697430255.JavaMail.zimbra@redhat.com>
References: <CADGJaX9P_CikxL8xLBqW1eBYTnYtrunymHL3KjheWJxxbu-g0A@mail.gmail.com>
	<433255762.13249435.1398697430255.JavaMail.zimbra@redhat.com>
Message-ID: <CANoTJYO5jHUtwAGaTZK3yZ9UBC3J6uR6VznUU35fT7_v7jfgSw@mail.gmail.com>

+1


On Mon, Apr 28, 2014 at 4:03 PM, Brett Meyer <brmeyer at redhat.com> wrote:

> +1 from me.  I have several to contribute as well from various ORM
> presentations.
>
> https://github.com/brmeyer/HibernateDemos
>
> ----- Original Message -----
> From: "Gunnar Morling" <gunnar at hibernate.org>
> To: hibernate-dev at lists.jboss.org
> Sent: Monday, April 28, 2014 10:49:19 AM
> Subject: [hibernate-dev] GitHub repo for demo projects
>
> Hi,
>
> Together with Sanne I've been creating a demo app which shows some features
> of Hibernate OGM.
>
> Right now this lives under my personal account on GitHub, but IMO it'd make
> sense to move it somewhere under https://github.com/hibernate/ to make it
> more visible, encourage re-use and contributions by others etc.
>
> What do you think about creating a repo under the hibernate organization
> such as "hibernate-demos" which could host this and other demos for our
> projects in the future? Or would it even make more sense on a per-project
> base ("hibernate-ogm-demos" etc.)?
>
> --Gunnar
>
> [1] https://github.com/gunnarmorling/ogm-hiking-demo
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From martinbraun123 at aol.com  Mon Apr 28 13:38:30 2014
From: martinbraun123 at aol.com (Martin Braun)
Date: Mon, 28 Apr 2014 13:38:30 -0400 (EDT)
Subject: [hibernate-dev] Fwd:  GitHub repo for demo projects
In-Reply-To: <8D1311F73BECE65-A30-213C3@webmail-m154.sysops.aol.com>
References: <CADGJaX9P_CikxL8xLBqW1eBYTnYtrunymHL3KjheWJxxbu-g0A@mail.gmail.com>
	<433255762.13249435.1398697430255.JavaMail.zimbra@redhat.com>
	<CANoTJYO5jHUtwAGaTZK3yZ9UBC3J6uR6VznUU35fT7_v7jfgSw@mail.gmail.com>
	<8D1311F73BECE65-A30-213C3@webmail-m154.sysops.aol.com>
Message-ID: <8D1311FCDE24583-A30-2140B@webmail-m154.sysops.aol.com>




+1


Martin Braun
martinbraun123 at aol.com
www.github.com/s4ke




-----Original Message-----
From: Davide D'Alto <daltodavide at gmail.com>
To: hibernate-dev <hibernate-dev at lists.jboss.org>
Sent: Mon, Apr 28, 2014 5:29 pm
Subject: Re: [hibernate-dev] GitHub repo for demo projects


+1


On Mon, Apr 28, 2014 at 4:03 PM, Brett Meyer <brmeyer at redhat.com> wrote:

> +1 from me.  I have several to contribute as well from various ORM
> presentations.
>
> https://github.com/brmeyer/HibernateDemos
>
> ----- Original Message -----
> From: "Gunnar Morling" <gunnar at hibernate.org>
> To: hibernate-dev at lists.jboss.org
> Sent: Monday, April 28, 2014 10:49:19 AM
> Subject: [hibernate-dev] GitHub repo for demo projects
>
> Hi,
>
> Together with Sanne I've been creating a demo app which shows some features
> of Hibernate OGM.
>
> Right now this lives under my personal account on GitHub, but IMO it'd make
> sense to move it somewhere under https://github.com/hibernate/ to make it
> more visible, encourage re-use and contributions by others etc.
>
> What do you think about creating a repo under the hibernate organization
> such as "hibernate-demos" which could host this and other demos for our
> projects in the future? Or would it even make more sense on a per-project
> base ("hibernate-ogm-demos" etc.)?
>
> --Gunnar
>
> [1] https://github.com/gunnarmorling/ogm-hiking-demo
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

 


From hardy at hibernate.org  Mon Apr 28 14:09:16 2014
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Mon, 28 Apr 2014 20:09:16 +0200
Subject: [hibernate-dev] Jandex, scanning and discovery
In-Reply-To: <CAFdSV9sjvGvifJkU+Bpk7QPpHpvR65zJBJC0d3XbE87Lqx6zuQ@mail.gmail.com>
References: <CAFdSV9tMbyjDE5qdAHhBUvTaXNC5W-YSAsvnfr3uXbJRS2UUWA@mail.gmail.com>
	<13900ADC-5394-44A3-AFB7-591F2121E766@hibernate.org>
	<CAFdSV9uwPrc4Oa0UGjOus9C3Pe71Av_dDB=2SXu2zFNAve_hoA@mail.gmail.com>
	<901F31BB-98CC-4704-8B38-DF633A62030C@hibernate.org>
	<CAFdSV9uYjXNScDk_Pz67gmqPoZkBF7_q=w7y9B7bmSAMZta3bA@mail.gmail.com>
	<CAFdSV9sjvGvifJkU+Bpk7QPpHpvR65zJBJC0d3XbE87Lqx6zuQ@mail.gmail.com>
Message-ID: <486345A4-6720-425E-8606-04B2D4BD732F@hibernate.org>


On 28 Jan 2014, at 17:20, Steve Ebersole <steve at hibernate.org> wrote:

> Almost done with this.  We are much more aggressive about indexing stuff into Jandex now (which is a good thing) when we are not handed a Jandex Index.  
> 
> However, this does mean we need to be more careful in the case of JPA and exclude-non-listed-classes.  ATM we drive annotations based on Jandex (aka, the classes known to Jandex).  However, if we know index classes that should not be used as entities, etc (because of exclude-non-listed-classes) we are breaking the JPA spec.  To this end, I suggest that scanning:
> 1) Index everything
> 2) Keep a running tab of "allowable managed classes and packages".
> 
> Later, when beginning interpretation of annotations (via Jandex) we can cross-reference that with the list of allowable managed classes.  Currently we do:
> 
> for ( ClassInfo classInfo : bindingContext.getJandexAccess().getIndex().getKnownClasses() ) {
>     // use them all...
> }
> 
> 
> What I am suggesting is:
> 
> interface ManagedClassFilter {
>     public boolean allowAsManagedClass(ClassInfo classInfo);
> }
> 
> for ( ClassInfo classInfo : bindingContext.getJandexAccess().getIndex().getKnownClasses() ) {
>     if ( !managedClassFiler.allowAsManagedClass( classInfo ) ) {
>         continue;
>     }
> }
> 
> Further, rather than maintaining potentially large lists of allowable class and package names, I'd also suggest we recognize the cases when we have open-ended discovery in play and simply use an "all inclusive" strategy.  

sounds good. 

From hardy at hibernate.org  Mon Apr 28 15:43:02 2014
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Mon, 28 Apr 2014 21:43:02 +0200
Subject: [hibernate-dev] [Search] Index embedded and id property of embedded
	entity
Message-ID: <2B79F125-4684-4B75-B617-B6F8CD71EFEF@hibernate.org>

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
	@IndexedEmbedded
	private B b;
}

@Entity
public class B {
	@Id
	@GeneratedValue
	private Timestamp id;

	@Field
	private String foo;

	public Timestamp getId() {
		return id;
	}

	public String getFoo() {
		return foo;
	}
}


A includes B via @IndexedEmbedded and is only interested in including the ?foo? field. However, atm we implicitly index B.id as well.
In this particular case an exception is thrown, because we don?t know which field bridge to use for B.id.

This also relates to HSEARCH-1092 [2], where the include path feature of @IndexedEmbedded is used. Even though the configured 
paths don?t include the ids, they are added which increases the index size unnecessarily (not really sure whether it really matters in practice).

If we skip the implicit inclusion of id properties, the user will need to add an explicit @Field in case he wants to include an id property via indexed
embedded. If the embedded entity itself is not indexed, I think this makes sense. But what if the embedded entity is indexed itself? Does it seem
wrong in this case to specify an additional @Field? Do we need some additional configuration element? 

Thoughts?

?Hardy


[1] https://hibernate.atlassian.net/browse/HSEARCH-1494
[2] https://hibernate.atlassian.net/browse/HSEARCH-1092 

From steve at hibernate.org  Mon Apr 28 17:56:13 2014
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 28 Apr 2014 16:56:13 -0500
Subject: [hibernate-dev] HEM "packaged" tests
Message-ID: <CAFdSV9s7Z4vt_zkFkL7W=LhBQe008RJorMAFSTGfsweFZJ8SSA@mail.gmail.com>

With my latest Scanner changes as outlined in the earlier email there is
one failure in the HEM "packaged" tests that I simply cannot explain why it
was previously considered valid.

The test
is org.hibernate.jpa.test.packaging.PackagedEntityManagerTest#testCfgXmlPar.

The test builds a PAR (via ShrinkWrap) and then tries to use it.  The
persistence.xml simply points to a cfg.xml.  The cfg.xml names 4 classes.
 But the PAR only bundles 2 of them.  The test fails because Binder cannot
find the other 2 classes.  Should this be valid?  Should the cfg.xml inside
a PAR be allowed to name classes not contained in the PAR?  Obviously if
the test is allowed to pick up all classes on the "real test classpath" the
test will pass.

From steve at hibernate.org  Mon Apr 28 17:59:02 2014
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 28 Apr 2014 16:59:02 -0500
Subject: [hibernate-dev] HEM "packaged" tests
In-Reply-To: <CAFdSV9s7Z4vt_zkFkL7W=LhBQe008RJorMAFSTGfsweFZJ8SSA@mail.gmail.com>
References: <CAFdSV9s7Z4vt_zkFkL7W=LhBQe008RJorMAFSTGfsweFZJ8SSA@mail.gmail.com>
Message-ID: <CAFdSV9upLA4AJHkf5NUwqSqimwqYnEbN9Tzvf0f=jnrp9pJ3gw@mail.gmail.com>

I should point out.. adding the additional named classes to the PAR also
leads to the test passing.




On Mon, Apr 28, 2014 at 4:56 PM, Steve Ebersole <steve at hibernate.org> wrote:

> With my latest Scanner changes as outlined in the earlier email there is
> one failure in the HEM "packaged" tests that I simply cannot explain why it
> was previously considered valid.
>
> The test
> is org.hibernate.jpa.test.packaging.PackagedEntityManagerTest#testCfgXmlPar.
>
> The test builds a PAR (via ShrinkWrap) and then tries to use it.  The
> persistence.xml simply points to a cfg.xml.  The cfg.xml names 4 classes.
>  But the PAR only bundles 2 of them.  The test fails because Binder cannot
> find the other 2 classes.  Should this be valid?  Should the cfg.xml inside
> a PAR be allowed to name classes not contained in the PAR?  Obviously if
> the test is allowed to pick up all classes on the "real test classpath" the
> test will pass.
>

From sanne at hibernate.org  Mon Apr 28 18:14:22 2014
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 28 Apr 2014 23:14:22 +0100
Subject: [hibernate-dev] [Search] Index embedded and id property of
 embedded entity
In-Reply-To: <2B79F125-4684-4B75-B617-B6F8CD71EFEF@hibernate.org>
References: <2B79F125-4684-4B75-B617-B6F8CD71EFEF@hibernate.org>
Message-ID: <CAFm4XO35e_7P5xGxZPdMoL8xc19Fk4_oZUxy7a3y81zHiiVkkA@mail.gmail.com>

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 relations is useful, so we should still
allow to add it when someone explicitly flags the need for it.

Now the complexity is I guess to define what it means to "explicitly
flag the need for it"; I think @IndexedEmbedded should not include it
by default, unless explicitly listed via the _includePaths_ attribute.

Question: would we still interpret the literal "id" as a keyword
pointing to whatever getter is the primary key of the embedded object?
I'm inclined to seek for a property which has the name as listed in
_includePaths_, not giving the "id" literal a special treatment in
this case.

Sanne



On 28 April 2014 20:43, Hardy Ferentschik <hardy at hibernate.org> wrote:
> 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
>         @IndexedEmbedded
>         private B b;
> }
>
> @Entity
> public class B {
>         @Id
>         @GeneratedValue
>         private Timestamp id;
>
>         @Field
>         private String foo;
>
>         public Timestamp getId() {
>                 return id;
>         }
>
>         public String getFoo() {
>                 return foo;
>         }
> }
>
>
> A includes B via @IndexedEmbedded and is only interested in including the ?foo? field. However, atm we implicitly index B.id as well.
> In this particular case an exception is thrown, because we don?t know which field bridge to use for B.id.
>
> This also relates to HSEARCH-1092 [2], where the include path feature of @IndexedEmbedded is used. Even though the configured
> paths don?t include the ids, they are added which increases the index size unnecessarily (not really sure whether it really matters in practice).
>
> If we skip the implicit inclusion of id properties, the user will need to add an explicit @Field in case he wants to include an id property via indexed
> embedded. If the embedded entity itself is not indexed, I think this makes sense. But what if the embedded entity is indexed itself? Does it seem
> wrong in this case to specify an additional @Field? Do we need some additional configuration element?
>
> Thoughts?
>
> ?Hardy
>
>
> [1] https://hibernate.atlassian.net/browse/HSEARCH-1494
> [2] https://hibernate.atlassian.net/browse/HSEARCH-1092
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


From sanne at hibernate.org  Mon Apr 28 18:21:35 2014
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 28 Apr 2014 23:21:35 +0100
Subject: [hibernate-dev] GitHub repo for demo projects
In-Reply-To: <CANoTJYO5jHUtwAGaTZK3yZ9UBC3J6uR6VznUU35fT7_v7jfgSw@mail.gmail.com>
References: <CADGJaX9P_CikxL8xLBqW1eBYTnYtrunymHL3KjheWJxxbu-g0A@mail.gmail.com>
	<433255762.13249435.1398697430255.JavaMail.zimbra@redhat.com>
	<CANoTJYO5jHUtwAGaTZK3yZ9UBC3J6uR6VznUU35fT7_v7jfgSw@mail.gmail.com>
Message-ID: <CAFm4XO28XG4OZL90Ykj_mYZvmScZ4ivK9gTpeEjT9L3e_pDAAw@mail.gmail.com>

Nice idea!
we could have each demo in a separate directory and put some
description for each in the root readme file.

But also the most polished demos, like if something evolves in being
extemely polished and well documented, should eventually be promoted
for inclusion in http://www.jboss.org/jdf/ . So I'd consider this more
of a lean sandbox, not something too formal? Or do we want to build
something to be pointed at from our documentation? That would
implicitly require some review and testing process at least.

Sanne


On 28 April 2014 16:28, Davide D'Alto <daltodavide at gmail.com> wrote:
> +1
>
>
> On Mon, Apr 28, 2014 at 4:03 PM, Brett Meyer <brmeyer at redhat.com> wrote:
>
>> +1 from me.  I have several to contribute as well from various ORM
>> presentations.
>>
>> https://github.com/brmeyer/HibernateDemos
>>
>> ----- Original Message -----
>> From: "Gunnar Morling" <gunnar at hibernate.org>
>> To: hibernate-dev at lists.jboss.org
>> Sent: Monday, April 28, 2014 10:49:19 AM
>> Subject: [hibernate-dev] GitHub repo for demo projects
>>
>> Hi,
>>
>> Together with Sanne I've been creating a demo app which shows some features
>> of Hibernate OGM.
>>
>> Right now this lives under my personal account on GitHub, but IMO it'd make
>> sense to move it somewhere under https://github.com/hibernate/ to make it
>> more visible, encourage re-use and contributions by others etc.
>>
>> What do you think about creating a repo under the hibernate organization
>> such as "hibernate-demos" which could host this and other demos for our
>> projects in the future? Or would it even make more sense on a per-project
>> base ("hibernate-ogm-demos" etc.)?
>>
>> --Gunnar
>>
>> [1] https://github.com/gunnarmorling/ogm-hiking-demo
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From gunnar at hibernate.org  Tue Apr 29 01:58:05 2014
From: gunnar at hibernate.org (Gunnar Morling)
Date: Tue, 29 Apr 2014 07:58:05 +0200
Subject: [hibernate-dev] GitHub repo for demo projects
In-Reply-To: <CAFm4XO28XG4OZL90Ykj_mYZvmScZ4ivK9gTpeEjT9L3e_pDAAw@mail.gmail.com>
References: <CADGJaX9P_CikxL8xLBqW1eBYTnYtrunymHL3KjheWJxxbu-g0A@mail.gmail.com>
	<433255762.13249435.1398697430255.JavaMail.zimbra@redhat.com>
	<CANoTJYO5jHUtwAGaTZK3yZ9UBC3J6uR6VznUU35fT7_v7jfgSw@mail.gmail.com>
	<CAFm4XO28XG4OZL90Ykj_mYZvmScZ4ivK9gTpeEjT9L3e_pDAAw@mail.gmail.com>
Message-ID: <CADGJaX-24cbXJePWoECZ=S-d2wWQ=kT78bLm2epxkj4AKpJGGw@mail.gmail.com>

2014-04-29 0:21 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:

> Nice idea!
> we could have each demo in a separate directory and put some
> description for each in the root readme file.
>

+1

But also the most polished demos, like if something evolves in being
> extemely polished and well documented, should eventually be promoted
> for inclusion in http://www.jboss.org/jdf/ . So I'd consider this more
> of a lean sandbox, not something too formal? Or do we want to build
> something to be pointed at from our documentation? That would
> implicitly require some review and testing process at least.
>

For now I had something rather informal in mind. Just a place where people
attending one of our talks can go and try out a demo themselves.

Of course individual demos from this "sandbox" may evolve over time into a
part of JDF or become part of the official documentation. As you say,
that'd require more polishing and documentation, but also updating to stay
in sync with the latest versions of our projects.

--Gunnar

Sanne
>
>
> On 28 April 2014 16:28, Davide D'Alto <daltodavide at gmail.com> wrote:
> > +1
> >
> >
> > On Mon, Apr 28, 2014 at 4:03 PM, Brett Meyer <brmeyer at redhat.com> wrote:
> >
> >> +1 from me.  I have several to contribute as well from various ORM
> >> presentations.
> >>
> >> https://github.com/brmeyer/HibernateDemos
> >>
> >> ----- Original Message -----
> >> From: "Gunnar Morling" <gunnar at hibernate.org>
> >> To: hibernate-dev at lists.jboss.org
> >> Sent: Monday, April 28, 2014 10:49:19 AM
> >> Subject: [hibernate-dev] GitHub repo for demo projects
> >>
> >> Hi,
> >>
> >> Together with Sanne I've been creating a demo app which shows some
> features
> >> of Hibernate OGM.
> >>
> >> Right now this lives under my personal account on GitHub, but IMO it'd
> make
> >> sense to move it somewhere under https://github.com/hibernate/ to make
> it
> >> more visible, encourage re-use and contributions by others etc.
> >>
> >> What do you think about creating a repo under the hibernate organization
> >> such as "hibernate-demos" which could host this and other demos for our
> >> projects in the future? Or would it even make more sense on a
> per-project
> >> base ("hibernate-ogm-demos" etc.)?
> >>
> >> --Gunnar
> >>
> >> [1] https://github.com/gunnarmorling/ogm-hiking-demo
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From gunnar at hibernate.org  Tue Apr 29 02:00:49 2014
From: gunnar at hibernate.org (Gunnar Morling)
Date: Tue, 29 Apr 2014 08:00:49 +0200
Subject: [hibernate-dev] GitHub repo for demo projects
In-Reply-To: <CADGJaX-24cbXJePWoECZ=S-d2wWQ=kT78bLm2epxkj4AKpJGGw@mail.gmail.com>
References: <CADGJaX9P_CikxL8xLBqW1eBYTnYtrunymHL3KjheWJxxbu-g0A@mail.gmail.com>
	<433255762.13249435.1398697430255.JavaMail.zimbra@redhat.com>
	<CANoTJYO5jHUtwAGaTZK3yZ9UBC3J6uR6VznUU35fT7_v7jfgSw@mail.gmail.com>
	<CAFm4XO28XG4OZL90Ykj_mYZvmScZ4ivK9gTpeEjT9L3e_pDAAw@mail.gmail.com>
	<CADGJaX-24cbXJePWoECZ=S-d2wWQ=kT78bLm2epxkj4AKpJGGw@mail.gmail.com>
Message-ID: <CADGJaX_=gzjz5NQdJsUTiXW815mTHV9EGC7DxqwQvpu9sDpg0g@mail.gmail.com>

2014-04-29 7:58 GMT+02:00 Gunnar Morling <gunnar at hibernate.org>:

> 2014-04-29 0:21 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
>
> Nice idea!
>> we could have each demo in a separate directory and put some
>> description for each in the root readme file.
>>
>
> +1
>
> But also the most polished demos, like if something evolves in being
>> extemely polished and well documented, should eventually be promoted
>> for inclusion in http://www.jboss.org/jdf/ . So I'd consider this more
>> of a lean sandbox, not something too formal? Or do we want to build
>> something to be pointed at from our documentation? That would
>> implicitly require some review and testing process at least.
>>
>
> For now I had something rather informal in mind. Just a place where people
> attending one of our talks can go and try out a demo themselves.
>
> Of course individual demos from this "sandbox" may evolve over time into a
> part of JDF or become part of the official documentation. As you say,
> that'd require more polishing and documentation, but also updating to stay
> in sync with the latest versions of our projects.
>

That said, if we agree on the idea, could you create a "hibernate-demos"
repository under the "hibernate" organization? I'm lacking the permission
to do so. I'll then add our demo and the root readme file so others can
follow.


>
> --Gunnar
>
> Sanne
>>
>>
>> On 28 April 2014 16:28, Davide D'Alto <daltodavide at gmail.com> wrote:
>> > +1
>> >
>> >
>> > On Mon, Apr 28, 2014 at 4:03 PM, Brett Meyer <brmeyer at redhat.com>
>> wrote:
>> >
>> >> +1 from me.  I have several to contribute as well from various ORM
>> >> presentations.
>> >>
>> >> https://github.com/brmeyer/HibernateDemos
>> >>
>> >> ----- Original Message -----
>> >> From: "Gunnar Morling" <gunnar at hibernate.org>
>> >> To: hibernate-dev at lists.jboss.org
>> >> Sent: Monday, April 28, 2014 10:49:19 AM
>> >> Subject: [hibernate-dev] GitHub repo for demo projects
>> >>
>> >> Hi,
>> >>
>> >> Together with Sanne I've been creating a demo app which shows some
>> features
>> >> of Hibernate OGM.
>> >>
>> >> Right now this lives under my personal account on GitHub, but IMO it'd
>> make
>> >> sense to move it somewhere under https://github.com/hibernate/ to
>> make it
>> >> more visible, encourage re-use and contributions by others etc.
>> >>
>> >> What do you think about creating a repo under the hibernate
>> organization
>> >> such as "hibernate-demos" which could host this and other demos for our
>> >> projects in the future? Or would it even make more sense on a
>> per-project
>> >> base ("hibernate-ogm-demos" etc.)?
>> >>
>> >> --Gunnar
>> >>
>> >> [1] https://github.com/gunnarmorling/ogm-hiking-demo
>> >> _______________________________________________
>> >> hibernate-dev mailing list
>> >> hibernate-dev at lists.jboss.org
>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >> _______________________________________________
>> >> hibernate-dev mailing list
>> >> hibernate-dev at lists.jboss.org
>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >>
>> > _______________________________________________
>> > hibernate-dev mailing list
>> > hibernate-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>

From sanne at hibernate.org  Tue Apr 29 05:19:38 2014
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 29 Apr 2014 10:19:38 +0100
Subject: [hibernate-dev] GitHub repo for demo projects
In-Reply-To: <CADGJaX_=gzjz5NQdJsUTiXW815mTHV9EGC7DxqwQvpu9sDpg0g@mail.gmail.com>
References: <CADGJaX9P_CikxL8xLBqW1eBYTnYtrunymHL3KjheWJxxbu-g0A@mail.gmail.com>
	<433255762.13249435.1398697430255.JavaMail.zimbra@redhat.com>
	<CANoTJYO5jHUtwAGaTZK3yZ9UBC3J6uR6VznUU35fT7_v7jfgSw@mail.gmail.com>
	<CAFm4XO28XG4OZL90Ykj_mYZvmScZ4ivK9gTpeEjT9L3e_pDAAw@mail.gmail.com>
	<CADGJaX-24cbXJePWoECZ=S-d2wWQ=kT78bLm2epxkj4AKpJGGw@mail.gmail.com>
	<CADGJaX_=gzjz5NQdJsUTiXW815mTHV9EGC7DxqwQvpu9sDpg0g@mail.gmail.com>
Message-ID: <CAFm4XO3rpbFKXgUS=40jkZ4EjLhzt7daoGU88y0YGMZhGHFWRA@mail.gmail.com>

Created https://github.com/hibernate/hibernate-demos

License: I've picked ASL2.. I guess that's ok for all our demos?

On 29 April 2014 07:00, Gunnar Morling <gunnar at hibernate.org> wrote:
> 2014-04-29 7:58 GMT+02:00 Gunnar Morling <gunnar at hibernate.org>:
>
>> 2014-04-29 0:21 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
>>
>>> Nice idea!
>>> we could have each demo in a separate directory and put some
>>> description for each in the root readme file.
>>
>>
>> +1
>>
>>> But also the most polished demos, like if something evolves in being
>>> extemely polished and well documented, should eventually be promoted
>>> for inclusion in http://www.jboss.org/jdf/ . So I'd consider this more
>>> of a lean sandbox, not something too formal? Or do we want to build
>>> something to be pointed at from our documentation? That would
>>> implicitly require some review and testing process at least.
>>
>>
>> For now I had something rather informal in mind. Just a place where people
>> attending one of our talks can go and try out a demo themselves.
>>
>> Of course individual demos from this "sandbox" may evolve over time into a
>> part of JDF or become part of the official documentation. As you say, that'd
>> require more polishing and documentation, but also updating to stay in sync
>> with the latest versions of our projects.
>
>
> That said, if we agree on the idea, could you create a "hibernate-demos"
> repository under the "hibernate" organization? I'm lacking the permission to
> do so. I'll then add our demo and the root readme file so others can follow.
>
>>
>>
>> --Gunnar
>>
>>> Sanne
>>>
>>>
>>> On 28 April 2014 16:28, Davide D'Alto <daltodavide at gmail.com> wrote:
>>> > +1
>>> >
>>> >
>>> > On Mon, Apr 28, 2014 at 4:03 PM, Brett Meyer <brmeyer at redhat.com>
>>> > wrote:
>>> >
>>> >> +1 from me.  I have several to contribute as well from various ORM
>>> >> presentations.
>>> >>
>>> >> https://github.com/brmeyer/HibernateDemos
>>> >>
>>> >> ----- Original Message -----
>>> >> From: "Gunnar Morling" <gunnar at hibernate.org>
>>> >> To: hibernate-dev at lists.jboss.org
>>> >> Sent: Monday, April 28, 2014 10:49:19 AM
>>> >> Subject: [hibernate-dev] GitHub repo for demo projects
>>> >>
>>> >> Hi,
>>> >>
>>> >> Together with Sanne I've been creating a demo app which shows some
>>> >> features
>>> >> of Hibernate OGM.
>>> >>
>>> >> Right now this lives under my personal account on GitHub, but IMO it'd
>>> >> make
>>> >> sense to move it somewhere under https://github.com/hibernate/ to make
>>> >> it
>>> >> more visible, encourage re-use and contributions by others etc.
>>> >>
>>> >> What do you think about creating a repo under the hibernate
>>> >> organization
>>> >> such as "hibernate-demos" which could host this and other demos for
>>> >> our
>>> >> projects in the future? Or would it even make more sense on a
>>> >> per-project
>>> >> base ("hibernate-ogm-demos" etc.)?
>>> >>
>>> >> --Gunnar
>>> >>
>>> >> [1] https://github.com/gunnarmorling/ogm-hiking-demo
>>> >> _______________________________________________
>>> >> hibernate-dev mailing list
>>> >> hibernate-dev at lists.jboss.org
>>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>> >> _______________________________________________
>>> >> hibernate-dev mailing list
>>> >> hibernate-dev at lists.jboss.org
>>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>> >>
>>> > _______________________________________________
>>> > hibernate-dev mailing list
>>> > hibernate-dev at lists.jboss.org
>>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>>
>

From gunnar at hibernate.org  Tue Apr 29 05:34:43 2014
From: gunnar at hibernate.org (Gunnar Morling)
Date: Tue, 29 Apr 2014 11:34:43 +0200
Subject: [hibernate-dev] GitHub repo for demo projects
In-Reply-To: <CAFm4XO3rpbFKXgUS=40jkZ4EjLhzt7daoGU88y0YGMZhGHFWRA@mail.gmail.com>
References: <CADGJaX9P_CikxL8xLBqW1eBYTnYtrunymHL3KjheWJxxbu-g0A@mail.gmail.com>
	<433255762.13249435.1398697430255.JavaMail.zimbra@redhat.com>
	<CANoTJYO5jHUtwAGaTZK3yZ9UBC3J6uR6VznUU35fT7_v7jfgSw@mail.gmail.com>
	<CAFm4XO28XG4OZL90Ykj_mYZvmScZ4ivK9gTpeEjT9L3e_pDAAw@mail.gmail.com>
	<CADGJaX-24cbXJePWoECZ=S-d2wWQ=kT78bLm2epxkj4AKpJGGw@mail.gmail.com>
	<CADGJaX_=gzjz5NQdJsUTiXW815mTHV9EGC7DxqwQvpu9sDpg0g@mail.gmail.com>
	<CAFm4XO3rpbFKXgUS=40jkZ4EjLhzt7daoGU88y0YGMZhGHFWRA@mail.gmail.com>
Message-ID: <CADGJaX_1jrYVozYTV-k66c4qXwJAqBPSy7i8M=33XFwQhNZY5A@mail.gmail.com>

2014-04-29 11:19 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:

> Created https://github.com/hibernate/hibernate-demos


Cool, thanks.

License: I've picked ASL2.. I guess that's ok for all our demos?
>

That seems reasonable to me.


>
> On 29 April 2014 07:00, Gunnar Morling <gunnar at hibernate.org> wrote:
> > 2014-04-29 7:58 GMT+02:00 Gunnar Morling <gunnar at hibernate.org>:
> >
> >> 2014-04-29 0:21 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
> >>
> >>> Nice idea!
> >>> we could have each demo in a separate directory and put some
> >>> description for each in the root readme file.
> >>
> >>
> >> +1
> >>
> >>> But also the most polished demos, like if something evolves in being
> >>> extemely polished and well documented, should eventually be promoted
> >>> for inclusion in http://www.jboss.org/jdf/ . So I'd consider this more
> >>> of a lean sandbox, not something too formal? Or do we want to build
> >>> something to be pointed at from our documentation? That would
> >>> implicitly require some review and testing process at least.
> >>
> >>
> >> For now I had something rather informal in mind. Just a place where
> people
> >> attending one of our talks can go and try out a demo themselves.
> >>
> >> Of course individual demos from this "sandbox" may evolve over time
> into a
> >> part of JDF or become part of the official documentation. As you say,
> that'd
> >> require more polishing and documentation, but also updating to stay in
> sync
> >> with the latest versions of our projects.
> >
> >
> > That said, if we agree on the idea, could you create a "hibernate-demos"
> > repository under the "hibernate" organization? I'm lacking the
> permission to
> > do so. I'll then add our demo and the root readme file so others can
> follow.
> >
> >>
> >>
> >> --Gunnar
> >>
> >>> Sanne
> >>>
> >>>
> >>> On 28 April 2014 16:28, Davide D'Alto <daltodavide at gmail.com> wrote:
> >>> > +1
> >>> >
> >>> >
> >>> > On Mon, Apr 28, 2014 at 4:03 PM, Brett Meyer <brmeyer at redhat.com>
> >>> > wrote:
> >>> >
> >>> >> +1 from me.  I have several to contribute as well from various ORM
> >>> >> presentations.
> >>> >>
> >>> >> https://github.com/brmeyer/HibernateDemos
> >>> >>
> >>> >> ----- Original Message -----
> >>> >> From: "Gunnar Morling" <gunnar at hibernate.org>
> >>> >> To: hibernate-dev at lists.jboss.org
> >>> >> Sent: Monday, April 28, 2014 10:49:19 AM
> >>> >> Subject: [hibernate-dev] GitHub repo for demo projects
> >>> >>
> >>> >> Hi,
> >>> >>
> >>> >> Together with Sanne I've been creating a demo app which shows some
> >>> >> features
> >>> >> of Hibernate OGM.
> >>> >>
> >>> >> Right now this lives under my personal account on GitHub, but IMO
> it'd
> >>> >> make
> >>> >> sense to move it somewhere under https://github.com/hibernate/ to
> make
> >>> >> it
> >>> >> more visible, encourage re-use and contributions by others etc.
> >>> >>
> >>> >> What do you think about creating a repo under the hibernate
> >>> >> organization
> >>> >> such as "hibernate-demos" which could host this and other demos for
> >>> >> our
> >>> >> projects in the future? Or would it even make more sense on a
> >>> >> per-project
> >>> >> base ("hibernate-ogm-demos" etc.)?
> >>> >>
> >>> >> --Gunnar
> >>> >>
> >>> >> [1] https://github.com/gunnarmorling/ogm-hiking-demo
> >>> >> _______________________________________________
> >>> >> hibernate-dev mailing list
> >>> >> hibernate-dev at lists.jboss.org
> >>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>> >> _______________________________________________
> >>> >> hibernate-dev mailing list
> >>> >> hibernate-dev at lists.jboss.org
> >>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>> >>
> >>> > _______________________________________________
> >>> > hibernate-dev mailing list
> >>> > hibernate-dev at lists.jboss.org
> >>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>> _______________________________________________
> >>> hibernate-dev mailing list
> >>> hibernate-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>
> >>
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From hardy at hibernate.org  Tue Apr 29 06:28:15 2014
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Tue, 29 Apr 2014 12:28:15 +0200
Subject: [hibernate-dev] [Search] Index embedded and id property of
	embedded entity
In-Reply-To: <CAFm4XO35e_7P5xGxZPdMoL8xc19Fk4_oZUxy7a3y81zHiiVkkA@mail.gmail.com>
References: <2B79F125-4684-4B75-B617-B6F8CD71EFEF@hibernate.org>
	<CAFm4XO35e_7P5xGxZPdMoL8xc19Fk4_oZUxy7a3y81zHiiVkkA@mail.gmail.com>
Message-ID: <F95E990E-1850-4EA8-BDF9-23CC2052132C@hibernate.org>


On 29 Jan 2014, at 00:14, Sanne Grinovero <sanne at hibernate.org> 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 there is a good reason for including the id of the embedded
entity by default, especially since it leads to potential problems as described in HSEARCH-1494.

> Some power users pointed out that there are use cases in which having
> the _id_ field of embedded relations is useful, so we should still
> allow to add it when someone explicitly flags the need for it.

Sure. My questions was basically about how we allow this type of id inclusion.

> Now the complexity is I guess to define what it means to "explicitly
> flag the need for it?;

exactly :-)

> I think @IndexedEmbedded should not include it
> by default, unless explicitly listed via the _includePaths_ attribute.

include paths is one use case, but there is also the default @IndexedEmbedded behaviour
which includes all indexed field (including the id atm).

> 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. 

> I'm inclined to seek for a property which has the name as listed in
> _includePaths_, not giving the "id" literal a special treatment in
> this case.

I am not following you here. What do you mean? Also you seem to just target the includePath case. 

Another thought would be to make this a global configuration option. Something like 
hibernate.search.embeddedindexing.include_id_property. Per default the flag would be false, but
could be set to true. Obviously this is a quite coarse solution. 

?Hardy

From sanne at hibernate.org  Tue Apr 29 07:03:23 2014
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 29 Apr 2014 12:03:23 +0100
Subject: [hibernate-dev] [Search] Index embedded and id property of
 embedded entity
In-Reply-To: <F95E990E-1850-4EA8-BDF9-23CC2052132C@hibernate.org>
References: <2B79F125-4684-4B75-B617-B6F8CD71EFEF@hibernate.org>
	<CAFm4XO35e_7P5xGxZPdMoL8xc19Fk4_oZUxy7a3y81zHiiVkkA@mail.gmail.com>
	<F95E990E-1850-4EA8-BDF9-23CC2052132C@hibernate.org>
Message-ID: <CAFm4XO0RGyEoCyO9u1G6xcjq8iu0JaFrA6c9apZ6RTyeXLGP+w@mail.gmail.com>

On 29 April 2014 11:28, Hardy Ferentschik <hardy at hibernate.org> wrote:
>
> On 29 Jan 2014, at 00:14, Sanne Grinovero <sanne at hibernate.org> 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 there is a good reason for including the id of the embedded
> entity by default, especially since it leads to potential problems as described in HSEARCH-1494.
>
>> Some power users pointed out that there are use cases in which having
>> the _id_ field of embedded relations is useful, so we should still
>> allow to add it when someone explicitly flags the need for it.
>
> Sure. My questions was basically about how we allow this type of id inclusion.
>
>> Now the complexity is I guess to define what it means to "explicitly
>> flag the need for it?;
>
> exactly :-)
>
>> I think @IndexedEmbedded should not include it
>> by default, unless explicitly listed via the _includePaths_ attribute.
>
> include paths is one use case, but there is also the default @IndexedEmbedded behaviour
> which includes all indexed field (including the id atm).
>
>> 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 for a moment that we would encode the
primary identifier as a specific keyword, but there's no reason.
Forget what I said :)

>
>> I'm inclined to seek for a property which has the name as listed in
>> _includePaths_, not giving the "id" literal a special treatment in
>> this case.
>
> I am not following you here. What do you mean? Also you seem to just target the includePath case.

Yes I mean we could never include it by default, and allow the
"includePath" to be the (only) way to include things.
Remember _includePath_ is additive to fields otherwise included via
@IndexedEmbedded _depth_, so it fits nicely for this role:

for non-indedex embedded elements it's of course nonsesense (as usual)
to specify an attribute which is lacking a @Field or similar option,
while for indexed types we implicitly apply one on the primary
identifier, this just needs to be selectable via _includePath_.

> Another thought would be to make this a global configuration option. Something like
> hibernate.search.embeddedindexing.include_id_property. Per default the flag would be false, but
> could be set to true. Obviously this is a quite coarse solution.

I wouldn't do that now, but we can certainly leave this option open
for future evolution.

Cheers,
Sanne

>
> ?Hardy


From hardy at hibernate.org  Tue Apr 29 07:45:37 2014
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Tue, 29 Apr 2014 13:45:37 +0200
Subject: [hibernate-dev] [Search] Index embedded and id property of
	embedded entity
In-Reply-To: <CAFm4XO0RGyEoCyO9u1G6xcjq8iu0JaFrA6c9apZ6RTyeXLGP+w@mail.gmail.com>
References: <2B79F125-4684-4B75-B617-B6F8CD71EFEF@hibernate.org>
	<CAFm4XO35e_7P5xGxZPdMoL8xc19Fk4_oZUxy7a3y81zHiiVkkA@mail.gmail.com>
	<F95E990E-1850-4EA8-BDF9-23CC2052132C@hibernate.org>
	<CAFm4XO0RGyEoCyO9u1G6xcjq8iu0JaFrA6c9apZ6RTyeXLGP+w@mail.gmail.com>
Message-ID: <05348290-FF9F-49E8-8790-816F5A6001B8@hibernate.org>


>>> 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 for a moment that we would encode the
> primary identifier as a specific keyword, but there's no reason.
> Forget what I said :)

:-)

>>> I'm inclined to seek for a property which has the name as listed in
>>> _includePaths_, not giving the "id" literal a special treatment in
>>> this case.
>> 
>> I am not following you here. What do you mean? Also you seem to just target the includePath case.
> 
> 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 are happy
to just use the default @IndexedEmbedded.

> 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. So you would have to include the id via includePath
and also set the depth explicitly to something > 0. I also find it not intuitive that this means:
"index all embedded fields up to the given depth, plus the specified paths?. 
I never liked how we baked depth and includePath into the same annotation. A dedicated annotation would
have been more appropriate. 

> for non-indedex embedded elements it's of course nonsesense (as usual)
> to specify an attribute which is lacking a @Field or similar option,
> while for indexed types we implicitly apply one on the primary
> identifier, this just needs to be selectable via _includePath_.

I am just not sure, whether we easily can tell when processing the embedded entity whether it is indexed or not.
Obviously that is an implementation detail, but we might have to jump through some hoops here (might be wrong).

>> Another thought would be to make this a global configuration option. Something like
>> hibernate.search.embeddedindexing.include_id_property. Per default the flag would be false, but
>> could be set to true. Obviously this is a quite coarse solution.
> 
> I wouldn't do that now, but we can certainly leave this option open
> for future evolution.

Ok.

?Hardy

From guillaume.smet at gmail.com  Tue Apr 29 08:49:11 2014
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Tue, 29 Apr 2014 14:49:11 +0200
Subject: [hibernate-dev] [Search] Index embedded and id property of
 embedded entity
In-Reply-To: <05348290-FF9F-49E8-8790-816F5A6001B8@hibernate.org>
References: <2B79F125-4684-4B75-B617-B6F8CD71EFEF@hibernate.org>
	<CAFm4XO35e_7P5xGxZPdMoL8xc19Fk4_oZUxy7a3y81zHiiVkkA@mail.gmail.com>
	<F95E990E-1850-4EA8-BDF9-23CC2052132C@hibernate.org>
	<CAFm4XO0RGyEoCyO9u1G6xcjq8iu0JaFrA6c9apZ6RTyeXLGP+w@mail.gmail.com>
	<05348290-FF9F-49E8-8790-816F5A6001B8@hibernate.org>
Message-ID: <CALt0+o8=z2DHCqJo2UjA3MisENMU7JmUP=AA7aEjdXMa=vsaTA@mail.gmail.com>

Hi,

On Tue, Apr 29, 2014 at 1:45 PM, Hardy Ferentschik <hardy at hibernate.org> 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 are happy
> to just use the default @IndexedEmbedded.

I think we should keep the id with the default @IndexedEmbedded. It
was weird to include the id when the includePath didn't ask for it but
it would be weird to not include the id with the default
@IndexedEmbedded.

-- 
Guillaume

From sanne at hibernate.org  Tue Apr 29 09:09:59 2014
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 29 Apr 2014 14:09:59 +0100
Subject: [hibernate-dev] [Search] Index embedded and id property of
 embedded entity
In-Reply-To: <05348290-FF9F-49E8-8790-816F5A6001B8@hibernate.org>
References: <2B79F125-4684-4B75-B617-B6F8CD71EFEF@hibernate.org>
	<CAFm4XO35e_7P5xGxZPdMoL8xc19Fk4_oZUxy7a3y81zHiiVkkA@mail.gmail.com>
	<F95E990E-1850-4EA8-BDF9-23CC2052132C@hibernate.org>
	<CAFm4XO0RGyEoCyO9u1G6xcjq8iu0JaFrA6c9apZ6RTyeXLGP+w@mail.gmail.com>
	<05348290-FF9F-49E8-8790-816F5A6001B8@hibernate.org>
Message-ID: <CAFm4XO0cs3fxEHPGJ2eGHtC_D8OOQPf-EgyG8CJzgpFX5HebGQ@mail.gmail.com>

On 29 April 2014 12:45, Hardy Ferentschik <hardy at hibernate.org> 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?
>>> all the time.
>>
>> Right I got confused. I thought for a moment that we would encode the
>> primary identifier as a specific keyword, but there's no reason.
>> Forget what I said :)
>
> :-)
>
>>>> I'm inclined to seek for a property which has the name as listed in
>>>> _includePaths_, not giving the "id" literal a special treatment in
>>>> this case.
>>>
>>> I am not following you here. What do you mean? Also you seem to just target the includePath case.
>>
>> 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 are happy
> to just use the default @IndexedEmbedded.
>
>> 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. So you would have to include the id via includePath
> and also set the depth explicitly to something > 0.

No it's additive. depth=n will add "all" @Field until depth=n, and it
*also* will add what is explicitly listed in includePath.
So asserting that "all" doesn't include fields which are missing
Hibernate Search indexing annotations is a quite natural implication.

The problem if any is that the default depth value is different
depending if you use includePath or not, but also the alternative
Integer.MAX_VALUE doesn't make much sense in practice as noone will
define queries on an unbounded path.

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 that this means:
> "index all embedded fields up to the given depth, plus the specified paths?.
> I never liked how we baked depth and includePath into the same annotation. A dedicated annotation would
> have been more appropriate.

We've been there and couldn't agree on a better proposal. Feel free to
reopen the case on a new thread, if you have a nice name in mind. But
ultimately remember the goal is to allow queries on a well-known list
of field names, and it would be great to validate for these queries,
so to have a clear definitions of which indexing and analysis options
are applied to each Lucene field, and how to apply a bi-directional
projection.. so I'm still skeptical on leaving too much freedoom, or
have multiple ways to achieve the same thing.

>> for non-indedex embedded elements it's of course nonsesense (as usual)
>> to specify an attribute which is lacking a @Field or similar option,
>> while for indexed types we implicitly apply one on the primary
>> identifier, this just needs to be selectable via _includePath_.
>
> I am just not sure, whether we easily can tell when processing the embedded entity whether it is indexed or not.
> Obviously that is an implementation detail, but we might have to jump through some hoops here (might be wrong).

right. I guess we'll have to try.

>
>>> Another thought would be to make this a global configuration option. Something like
>>> hibernate.search.embeddedindexing.include_id_property. Per default the flag would be false, but
>>> could be set to true. Obviously this is a quite coarse solution.
>>
>> I wouldn't do that now, but we can certainly leave this option open
>> for future evolution.
>
> Ok.
>
> ?Hardy


From sanne at hibernate.org  Tue Apr 29 09:24:18 2014
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 29 Apr 2014 14:24:18 +0100
Subject: [hibernate-dev] [Search] Index embedded and id property of
 embedded entity
In-Reply-To: <CALt0+o8=z2DHCqJo2UjA3MisENMU7JmUP=AA7aEjdXMa=vsaTA@mail.gmail.com>
References: <2B79F125-4684-4B75-B617-B6F8CD71EFEF@hibernate.org>
	<CAFm4XO35e_7P5xGxZPdMoL8xc19Fk4_oZUxy7a3y81zHiiVkkA@mail.gmail.com>
	<F95E990E-1850-4EA8-BDF9-23CC2052132C@hibernate.org>
	<CAFm4XO0RGyEoCyO9u1G6xcjq8iu0JaFrA6c9apZ6RTyeXLGP+w@mail.gmail.com>
	<05348290-FF9F-49E8-8790-816F5A6001B8@hibernate.org>
	<CALt0+o8=z2DHCqJo2UjA3MisENMU7JmUP=AA7aEjdXMa=vsaTA@mail.gmail.com>
Message-ID: <CAFm4XO3xOnn0tBjMKbLaDMjDvpugaMFf+8gch4JJHzvy8pBk=A@mail.gmail.com>

On 29 April 2014 13:49, Guillaume Smet <guillaume.smet at gmail.com> wrote:
> Hi,
>
> On Tue, Apr 29, 2014 at 1:45 PM, Hardy Ferentschik <hardy at hibernate.org> 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 are happy
>> to just use the default @IndexedEmbedded.
>
> I think we should keep the id with the default @IndexedEmbedded. It
> was weird to include the id when the includePath didn't ask for it but
> it would be weird to not include the id with the default
> @IndexedEmbedded.

It's not an indexed field, I don't think it was ever meant to be in
the index but rather a side effect of our recursion.. as we obviously
need the id of the root element.

I'm sure there are some good use cases for it, but here are my reasons
to prefer the field to be removed by default:
- API wise it's much more complex to express the request-for-removal
than to simply add it to includePath when needed
- Lucene4 includes a special payload encoding for "id like fields"
which has lots of benefits, with the one drawback that it has to be
unique per document. We should aim at supporting it, but embedded
collections would violate the uniqueness of the field instance in the
Document, so force us to actually encode this case in a different
way.. I guess we could explore it but encoding consistency becomes
puzzling.
- Index size matters a lot on query performance (especially on native
IO buffers), and what most affects index size is stored Fields.. like
ID. I think most people will have no use for this id field and will
probably not notice this additional optimisation opportunity.

Am I missing some strong use case which needs this, for which
explicitly listing it on includePath is too annoying?
Also by simply removing it I hope to give some more control back to
user (as we'll obviously honour any bridge/@Field annotation), as this
id-indexing behaviour has caused other related discussions:
HSEARCH-183

Sanne

>
> --
> Guillaume

From brmeyer at redhat.com  Tue Apr 29 10:23:37 2014
From: brmeyer at redhat.com (Brett Meyer)
Date: Tue, 29 Apr 2014 10:23:37 -0400 (EDT)
Subject: [hibernate-dev] GitHub repo for demo projects
In-Reply-To: <CAFm4XO3rpbFKXgUS=40jkZ4EjLhzt7daoGU88y0YGMZhGHFWRA@mail.gmail.com>
References: <CADGJaX9P_CikxL8xLBqW1eBYTnYtrunymHL3KjheWJxxbu-g0A@mail.gmail.com>
	<433255762.13249435.1398697430255.JavaMail.zimbra@redhat.com>
	<CANoTJYO5jHUtwAGaTZK3yZ9UBC3J6uR6VznUU35fT7_v7jfgSw@mail.gmail.com>
	<CAFm4XO28XG4OZL90Ykj_mYZvmScZ4ivK9gTpeEjT9L3e_pDAAw@mail.gmail.com>
	<CADGJaX-24cbXJePWoECZ=S-d2wWQ=kT78bLm2epxkj4AKpJGGw@mail.gmail.com>
	<CADGJaX_=gzjz5NQdJsUTiXW815mTHV9EGC7DxqwQvpu9sDpg0g@mail.gmail.com>
	<CAFm4XO3rpbFKXgUS=40jkZ4EjLhzt7daoGU88y0YGMZhGHFWRA@mail.gmail.com>
Message-ID: <775298646.14143302.1398781417803.JavaMail.zimbra@redhat.com>

While we're on this subject, it's been suggested that having simple quickstart projects for testcase development would be helpful.  For example, see https://hibernate.atlassian.net/browse/HHH-9105.  Big +1 from me -- it would be great to point JIRA reporters towards the quickstart when asking for a reproducer.  Where should we control those?  /hibernate-testcase-quickstarts?

----- Original Message -----
From: "Sanne Grinovero" <sanne at hibernate.org>
To: "Gunnar Morling" <gunnar at hibernate.org>
Cc: "hibernate-dev" <hibernate-dev at lists.jboss.org>
Sent: Tuesday, April 29, 2014 5:19:38 AM
Subject: Re: [hibernate-dev] GitHub repo for demo projects

Created https://github.com/hibernate/hibernate-demos

License: I've picked ASL2.. I guess that's ok for all our demos?

On 29 April 2014 07:00, Gunnar Morling <gunnar at hibernate.org> wrote:
> 2014-04-29 7:58 GMT+02:00 Gunnar Morling <gunnar at hibernate.org>:
>
>> 2014-04-29 0:21 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
>>
>>> Nice idea!
>>> we could have each demo in a separate directory and put some
>>> description for each in the root readme file.
>>
>>
>> +1
>>
>>> But also the most polished demos, like if something evolves in being
>>> extemely polished and well documented, should eventually be promoted
>>> for inclusion in http://www.jboss.org/jdf/ . So I'd consider this more
>>> of a lean sandbox, not something too formal? Or do we want to build
>>> something to be pointed at from our documentation? That would
>>> implicitly require some review and testing process at least.
>>
>>
>> For now I had something rather informal in mind. Just a place where people
>> attending one of our talks can go and try out a demo themselves.
>>
>> Of course individual demos from this "sandbox" may evolve over time into a
>> part of JDF or become part of the official documentation. As you say, that'd
>> require more polishing and documentation, but also updating to stay in sync
>> with the latest versions of our projects.
>
>
> That said, if we agree on the idea, could you create a "hibernate-demos"
> repository under the "hibernate" organization? I'm lacking the permission to
> do so. I'll then add our demo and the root readme file so others can follow.
>
>>
>>
>> --Gunnar
>>
>>> Sanne
>>>
>>>
>>> On 28 April 2014 16:28, Davide D'Alto <daltodavide at gmail.com> wrote:
>>> > +1
>>> >
>>> >
>>> > On Mon, Apr 28, 2014 at 4:03 PM, Brett Meyer <brmeyer at redhat.com>
>>> > wrote:
>>> >
>>> >> +1 from me.  I have several to contribute as well from various ORM
>>> >> presentations.
>>> >>
>>> >> https://github.com/brmeyer/HibernateDemos
>>> >>
>>> >> ----- Original Message -----
>>> >> From: "Gunnar Morling" <gunnar at hibernate.org>
>>> >> To: hibernate-dev at lists.jboss.org
>>> >> Sent: Monday, April 28, 2014 10:49:19 AM
>>> >> Subject: [hibernate-dev] GitHub repo for demo projects
>>> >>
>>> >> Hi,
>>> >>
>>> >> Together with Sanne I've been creating a demo app which shows some
>>> >> features
>>> >> of Hibernate OGM.
>>> >>
>>> >> Right now this lives under my personal account on GitHub, but IMO it'd
>>> >> make
>>> >> sense to move it somewhere under https://github.com/hibernate/ to make
>>> >> it
>>> >> more visible, encourage re-use and contributions by others etc.
>>> >>
>>> >> What do you think about creating a repo under the hibernate
>>> >> organization
>>> >> such as "hibernate-demos" which could host this and other demos for
>>> >> our
>>> >> projects in the future? Or would it even make more sense on a
>>> >> per-project
>>> >> base ("hibernate-ogm-demos" etc.)?
>>> >>
>>> >> --Gunnar
>>> >>
>>> >> [1] https://github.com/gunnarmorling/ogm-hiking-demo
>>> >> _______________________________________________
>>> >> hibernate-dev mailing list
>>> >> hibernate-dev at lists.jboss.org
>>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>> >> _______________________________________________
>>> >> hibernate-dev mailing list
>>> >> hibernate-dev at lists.jboss.org
>>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>> >>
>>> > _______________________________________________
>>> > hibernate-dev mailing list
>>> > hibernate-dev at lists.jboss.org
>>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>>
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

From hardy at hibernate.org  Tue Apr 29 14:27:42 2014
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Tue, 29 Apr 2014 20:27:42 +0200
Subject: [hibernate-dev] [Search] Index embedded and id property of
	embedded entity
In-Reply-To: <CAFm4XO0cs3fxEHPGJ2eGHtC_D8OOQPf-EgyG8CJzgpFX5HebGQ@mail.gmail.com>
References: <2B79F125-4684-4B75-B617-B6F8CD71EFEF@hibernate.org>
	<CAFm4XO35e_7P5xGxZPdMoL8xc19Fk4_oZUxy7a3y81zHiiVkkA@mail.gmail.com>
	<F95E990E-1850-4EA8-BDF9-23CC2052132C@hibernate.org>
	<CAFm4XO0RGyEoCyO9u1G6xcjq8iu0JaFrA6c9apZ6RTyeXLGP+w@mail.gmail.com>
	<05348290-FF9F-49E8-8790-816F5A6001B8@hibernate.org>
	<CAFm4XO0cs3fxEHPGJ2eGHtC_D8OOQPf-EgyG8CJzgpFX5HebGQ@mail.gmail.com>
Message-ID: <7C072CDB-5FE0-4CF9-8159-3F722834910F@hibernate.org>


>>> 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. So you would have to include the id via includePath
>> and also set the depth explicitly to something > 0.
> 
> No it's additive. depth=n will add "all" @Field until depth=n, and it
> *also* will add what is explicitly listed in includePath.

Sure. What I meant that just adding a single include path changes the depth value.
I understand how it a depth > 0 and include path work in combination.

> So asserting that "all" doesn't include fields which are missing
> Hibernate Search indexing annotations is a quite natural implication.

?

> The problem if any is that the default depth value is different
> depending if you use includePath or not

exactly

> but also the alternative
> Integer.MAX_VALUE doesn't make much sense in practice as noone will
> define queries on an unbounded path.

hmmm, I guess you have a point here. At least at query time you need to know which
fields you are targeting. Unless of course we would support an empty prefix for index embedded. 
That?s requested in HSEARCH-183, but at the same time our documentation has a note
saying: "The prefix cannot be set to the empty string.? 

I added a quick test and there seems to be verification that the prefix is not the empty string.
If we allowed an empty prefix then unbounded inclusion makes sense. Either way, probably a good
time to address HSEARCH-183 as well. One way or the other.

> 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.

It would be a shame in this case that the default annotation basically is an ?invalid? configuration. 
If we go down this path where we either require a depth > 0 or at least one include path, I would 
go further than just logging a warning. I think we should throw an exception in case. This is probably 
also better for people who upgrade from Search 4 to 5. Messages can be ignored or depending on the 
log level even won?t show up and suddenly we get everyone asking why their app does not work anymore.
Throwing an exception would force people to make an active choice.

>> I also find it not intuitive that this means:
>> "index all embedded fields up to the given depth, plus the specified paths?.
>> I never liked how we baked depth and includePath into the same annotation. A dedicated annotation would
>> have been more appropriate.
> 
> We've been there and couldn't agree on a better proposal. Feel free to
> reopen the case on a new thread, if you have a nice name in mind.

I think I lost this one. I have no reason to believe that this has changed. I would have been easy on the names, but
dedicated annotation was what I was after. 

?Hardy

From hardy at hibernate.org  Tue Apr 29 14:43:57 2014
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Tue, 29 Apr 2014 20:43:57 +0200
Subject: [hibernate-dev] [Search] Index embedded and id property of
	embedded entity
In-Reply-To: <CAFm4XO3xOnn0tBjMKbLaDMjDvpugaMFf+8gch4JJHzvy8pBk=A@mail.gmail.com>
References: <2B79F125-4684-4B75-B617-B6F8CD71EFEF@hibernate.org>
	<CAFm4XO35e_7P5xGxZPdMoL8xc19Fk4_oZUxy7a3y81zHiiVkkA@mail.gmail.com>
	<F95E990E-1850-4EA8-BDF9-23CC2052132C@hibernate.org>
	<CAFm4XO0RGyEoCyO9u1G6xcjq8iu0JaFrA6c9apZ6RTyeXLGP+w@mail.gmail.com>
	<05348290-FF9F-49E8-8790-816F5A6001B8@hibernate.org>
	<CALt0+o8=z2DHCqJo2UjA3MisENMU7JmUP=AA7aEjdXMa=vsaTA@mail.gmail.com>
	<CAFm4XO3xOnn0tBjMKbLaDMjDvpugaMFf+8gch4JJHzvy8pBk=A@mail.gmail.com>
Message-ID: <8FA0E7E2-4ABC-4E56-A225-11DB7BA1B99F@hibernate.org>


On 29 Jan 2014, at 15:24, Sanne Grinovero <sanne at hibernate.org> 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
>> was weird to include the id when the includePath didn't ask for it but
>> it would be weird to not include the id with the default
>> @IndexedEmbedded.
> 
> It's not an indexed field, I don't think it was ever meant to be in
> the index but rather a side effect of our recursion.. as we obviously
> need the id of the root element.

Nope, the code is quite explicit. It contains a if/else statement checking whether 
we are processing the root entity and in the else part the comment says:
?// component should index their document id?

This is also not just an outcome of the metadata refactoring, since this if statement 
and comment also has been there in the DocumentBuilder code [1] 

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 include path, but what I want to make sure that our implementation
makes sense in all cases and we have a comprehensible solution for users. 
So, I guess you are saying here, that the document id is just not a regular field. 

> - Lucene4 includes a special payload encoding for "id like fields"
> which has lots of benefits, with the one drawback that it has to be
> unique per document.

Interesting. Do you have a pointer to this functionality?

> We should aim at supporting it

Sounds good.

> Am I missing some strong use case which needs this, for which
> explicitly listing it on includePath is too annoying?

As said, it needs to make sense as a whole. 

> Also by simply removing it I hope to give some more control back to
> user (as we'll obviously honour any bridge/@Field annotation), as this
> id-indexing behaviour has caused other related discussions:
> HSEARCH-183

I want to address HSEARCH-183 as well, just not sure your proposal is a 
requirement for that.

I was hoping HSEARCH-1494 would be an easy one, but it seems this goes much deeper ;-)

?Hardy

[1] https://github.com/hibernate/hibernate-search/blob/4.1/hibernate-search-engine/src/main/java/org/hibernate/search/engine/spi/DocumentBuilderIndexedEntity.java#L276



From steve at hibernate.org  Wed Apr 30 13:30:54 2014
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 30 Apr 2014 12:30:54 -0500
Subject: [hibernate-dev] Jandex, scanning and discovery
In-Reply-To: <486345A4-6720-425E-8606-04B2D4BD732F@hibernate.org>
References: <CAFdSV9tMbyjDE5qdAHhBUvTaXNC5W-YSAsvnfr3uXbJRS2UUWA@mail.gmail.com>
	<13900ADC-5394-44A3-AFB7-591F2121E766@hibernate.org>
	<CAFdSV9uwPrc4Oa0UGjOus9C3Pe71Av_dDB=2SXu2zFNAve_hoA@mail.gmail.com>
	<901F31BB-98CC-4704-8B38-DF633A62030C@hibernate.org>
	<CAFdSV9uYjXNScDk_Pz67gmqPoZkBF7_q=w7y9B7bmSAMZta3bA@mail.gmail.com>
	<CAFdSV9sjvGvifJkU+Bpk7QPpHpvR65zJBJC0d3XbE87Lqx6zuQ@mail.gmail.com>
	<486345A4-6720-425E-8606-04B2D4BD732F@hibernate.org>
Message-ID: <CAFdSV9tbahgiSWsThjW+WMnCoUhEJ+zb9WhP2UJPcScLJk9FTg@mail.gmail.com>

I am contemplating something very drastic here.  The back story is that we
end up needing to index stuff from 2 places: the
EntityManagerFactoryBuilder and again from MetadataBuildingProcess (part of
Binder processing).  The indexing from EntityManagerFactoryBuilder happens
just during JPA bootstrapping.  The indexing from MetadataBuildingProcess
happens for both.  The difficulty this presents is that we end up needing
to pass the same Indexer to both.

What I started thinking would be better is to perform all the indexing from
MetadataBuildingProcess.  But given the idea to perform a full index of all
classes as we scan, that would also mean moving scanning
into MetadataBuildingProcess.  Which I do not think is a bad idea (in fact
in isolation I think its a great idea).  My concern is more that atm this
is exposed as an SPI from HEM under the o.h.jpa package.  I could just move
the package in total to hibernate-core, I'm just ecstatic about a o.h.jpa
package being used for stuff that is (no longer) JPA specific.  But maybe
that's ok i the short term?  Could also do a "ghost package" concept
(deprecate old package and have it extend from new package) to help
integrators in the short term.

I have already made scanning not dependent upon the JPA spis.  Used to be
that scanning operated on the PersistenceUnitDescriptor.  But really we
just need a small subset of that information to actually perform scanning:
1) what is the root url?
2) what are the non-root urls?

Not really needed for scanning, but needed in collecting the scan results:
1) list of explicitly provided class names
2) list of explicitly provided mapping file names

So bottom line... none of this is JPA specific any more.  Moving scanning
to MetadataBuildingProcess allows us to centralize indexing in one place.

Thoughts?


On Mon, Apr 28, 2014 at 1:09 PM, Hardy Ferentschik <hardy at hibernate.org>wrote:

>
> On 28 Jan 2014, at 17:20, Steve Ebersole <steve at hibernate.org> wrote:
>
> > Almost done with this.  We are much more aggressive about indexing stuff
> into Jandex now (which is a good thing) when we are not handed a Jandex
> Index.
> >
> > However, this does mean we need to be more careful in the case of JPA
> and exclude-non-listed-classes.  ATM we drive annotations based on Jandex
> (aka, the classes known to Jandex).  However, if we know index classes that
> should not be used as entities, etc (because of exclude-non-listed-classes)
> we are breaking the JPA spec.  To this end, I suggest that scanning:
> > 1) Index everything
> > 2) Keep a running tab of "allowable managed classes and packages".
> >
> > Later, when beginning interpretation of annotations (via Jandex) we can
> cross-reference that with the list of allowable managed classes.  Currently
> we do:
> >
> > for ( ClassInfo classInfo :
> bindingContext.getJandexAccess().getIndex().getKnownClasses() ) {
> >     // use them all...
> > }
> >
> >
> > What I am suggesting is:
> >
> > interface ManagedClassFilter {
> >     public boolean allowAsManagedClass(ClassInfo classInfo);
> > }
> >
> > for ( ClassInfo classInfo :
> bindingContext.getJandexAccess().getIndex().getKnownClasses() ) {
> >     if ( !managedClassFiler.allowAsManagedClass( classInfo ) ) {
> >         continue;
> >     }
> > }
> >
> > Further, rather than maintaining potentially large lists of allowable
> class and package names, I'd also suggest we recognize the cases when we
> have open-ended discovery in play and simply use an "all inclusive"
> strategy.
>
> sounds good.

From hardy at hibernate.org  Wed Apr 30 14:19:52 2014
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Wed, 30 Apr 2014 20:19:52 +0200
Subject: [hibernate-dev] [Search] Index embedded and id property of
	embedded entity
In-Reply-To: <8FA0E7E2-4ABC-4E56-A225-11DB7BA1B99F@hibernate.org>
References: <2B79F125-4684-4B75-B617-B6F8CD71EFEF@hibernate.org>
	<CAFm4XO35e_7P5xGxZPdMoL8xc19Fk4_oZUxy7a3y81zHiiVkkA@mail.gmail.com>
	<F95E990E-1850-4EA8-BDF9-23CC2052132C@hibernate.org>
	<CAFm4XO0RGyEoCyO9u1G6xcjq8iu0JaFrA6c9apZ6RTyeXLGP+w@mail.gmail.com>
	<05348290-FF9F-49E8-8790-816F5A6001B8@hibernate.org>
	<CALt0+o8=z2DHCqJo2UjA3MisENMU7JmUP=AA7aEjdXMa=vsaTA@mail.gmail.com>
	<CAFm4XO3xOnn0tBjMKbLaDMjDvpugaMFf+8gch4JJHzvy8pBk=A@mail.gmail.com>
	<8FA0E7E2-4ABC-4E56-A225-11DB7BA1B99F@hibernate.org>
Message-ID: <FD83D72C-A5A5-43F0-A86C-61FE822E1528@hibernate.org>


> 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 include path, but what I want to make sure that our implementation
> makes sense in all cases and we have a comprehensible solution for users. 
> So, I guess you are saying here, that the document id is just not a regular field. 

To clarify what bugs me is, that you are basically suggesting that the id can be included via
include path, but can never be used via the depth approach. 

One option we have not discussed yet, is an additional method on @indexedEmbedded. 
Something like includeEmbeddedId. Default would be false. If you set it to true, the id is
included. It makes id inclusion orthogonal to depth and includePath.

?Hardy

From maheshgadgil at hotmail.com  Wed Apr 30 16:10:10 2014
From: maheshgadgil at hotmail.com (Mahesh Gadgil)
Date: Wed, 30 Apr 2014 20:10:10 +0000
Subject: [hibernate-dev] Build failure executing
	:hibernate-core:runAnnotationProcessors
Message-ID: <BLU170-W70926413B0CC9FD4C6872AD5410@phx.gbl>

I am facing the same issue Gale Badner mentioned in his email (hibernate-core:runAnnotationProcessors - BUILD FAILED) -
Gail Badner Fri, 28 Mar 2014 16:35:18 -0700.
but unlike him I am unable to resolve the issue. I am using java 1.7.0_51 and tried to compile 4.3 branch.

ThanksMahesh