Re: [hibernate-dev] Hibernate.next version and AS 7.2 community release...
by Steve Ebersole
Hardy, could the API be fixed up? I have not used it enough to be able
to tell if it is salvageable; only enough to know it needs changing ;)
On Tue 26 Jun 2012 02:54:11 PM CDT, Steve Ebersole wrote:
> Hardy, could the API be fixed up? I have not used it enough to be
> able to tell if it is salvageable (only enough to know it needs
> changing ;)
>
> On Tue 26 Jun 2012 02:37:02 PM CDT, Sanne Grinovero wrote:
>> Ok that sounds all nice. But we need programmatic definition of
>> annotations too, you remember Hibernate Search right?
>>
>> The first point you make about the XClass abstraction sounds to me a
>> good one, a good reason to use it. It doesn't have to be big and
>> bloated, but if we have a simple way to abstract from the annotation
>> reading
>> - XML
>> - Class definitions
>> - programmatic overrides
>>
>> in a single API, that sounds like a good thing? You mention this API
>> is confusing, maybe we can improve on it? Sounds better than to have
>> to deal with the three sources independently.
>>
>> On 26 June 2012 20:29, Hardy Ferentschik <hardy(a)hibernate.org> wrote:
>>>
>>> On Jun 26, 2012, at 9:02 PM, Sanne Grinovero wrote:
>>>
>>>> There are a lot of libraries depending on Hibernate Commons
>>>> Annotations, up to Infinispan for the Query module (not depending on
>>>> any other Hibernate core library).
>>>>
>>>> If you want to rewrite it's internals and provide a drop-in
>>>> replacement, that's nice. But I see no reason to throw it away?
>>>
>>> Sure, here we go.
>>>
>>> Commons Annotations tries to do two things at the same time.
>>>
>>> First there is the annotation abstraction, hiding the fact whether
>>> an annotation is an actual annotation
>>> or a corresponding xml configuration element. It does this by
>>> introducing XClass & Co.
>>> And that's the first rub. Working with XClass is highly confusing.
>>> You never know whether you
>>> deal w/ an XClass or an actual Class instance. Working on the ORM
>>> annotation processing code you have often
>>> have methods you get one or the other. Confusing!
>>>
>>> Also, working with Jandex you get the actual annotation vs xml
>>> configuration much easier. Jandex itself abstracts already an
>>> annotation.
>>> Hence you just have to implement the right Jandex classes to create
>>> pseudo annotation (annotation backed by xml configuration). Using
>>> Jandex
>>> in combination with Commons Annotations would mean you would
>>> abstract the abstraction.
>>>
>>> Back to the two things Commons Annotation tries to do. Commons
>>> Annotation also does generic type resolution.
>>> IMO this two things should be separate. There is annotation
>>> processing and there is type resolution. I often don't need
>>> both, but just one of them. Using a library like classmate can
>>> easily do the type resolution when I need it in a much more
>>> transparent way. The code is actually easily understandable. It is
>>> much harder to understand how the corresponding Commons Annotation
>>> code works.
>>>
>>> Regarding your reinventing the wheel argument. The metamodel branch
>>> already successfully removed the Commons Annotation
>>> dependency. Jandex offers all we need and Strong implemented some
>>> classes which create pseudo
>>> annotations for the xml config. The type resolution was replaced by
>>> classmate. Bottom line is that Commons Annotations is already
>>> replaced on the metamodel branch.
>>>
>>> Last but not least, I am definitely not the guy who wants to rewrite
>>> working just for the sake of it. However, if I see that there are
>>> better
>>> alternatives for existing code which results in easier to understand
>>> code I go for it.
>>>
>>> --Hardy
>>>
--
steve(a)hibernate.org
http://hibernate.org
12 years, 1 month
Re: [hibernate-dev] Hibernate.next version and AS 7.2 community release...
by Steve Ebersole
Well I think one option would be to explore using Jandex within
commons-annotations. Jandex is meant as a very lightweight (read:
FAST) annotation reader. commons-annotations is meant to read
annotations and merge the annotated values with xml overrides. But
commons-annotations could certainly use Jandex for the "read
annotations" portion of its mandate (I think). I think
commons-annotations is slow also because of how it reads XML. Reading
XML is always going to be a balance between (relative) speed and
readability/maintainability. In the new ORM code, we moved to StAX +
JAXB. My preliminary testing showed that to be a pretty great
compromise on that balance scale. But commons-annotations does not at
all work with JAXB nor JAXP. As far as I know it just directly used
dom4j apis (granted most likely because that is what ORM used).
And for the record, I never said throw commons annotations away.
Stopping using it in a particular project moving forward is much
different. I just don't think it makes sense to write "throw away
code". I'd avoid fixing commons-annotations and retrofitting fixes
into the old org.hibernate.mapping package. We know that code is going
away. If someone wants to write such throw away code, be my guest :)
On Tue 26 Jun 2012 01:39:30 PM CDT, Steve Ebersole wrote:
> Agree 10,000%
>
>
> On Tue 26 Jun 2012 11:29:04 AM CDT, Hardy Ferentschik wrote:
>>
>> On Jun 26, 2012, at 6:19 PM, Sanne Grinovero wrote:
>>
>>> an optimization we have been discussing but had still no time to
>>> implement is to update hibernate-commons-annotations to use Jandex.
>>
>> +1 for Jandex. However, I don't think it is worth to trying to use it
>> with the old configuration code.
>> The new metamodel will use jandex and I rather see that we get this
>> work complete instead of
>> making major changes to the existing annotation processing. That's
>> kind of doing twice the work.
>>
>> -1 for updating hibernate-commons-annotations. I think we should get
>> rid of it.
>>
>> --Hardy
>>
>>
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
--
steve(a)hibernate.org
http://hibernate.org
12 years, 1 month
A fine grained way to mark @Transient and @ClassBridges as dirty
by Marc Schipperheyn
@Transient @Field and @ClassBridges mark methods and classes dirty by
default because there is currently no way for HSearch to know which fields
are managed here. In the case of @Transient @Field this will often be ok,
because it will only lead to some superfluous extra indexing which is not a
big hit on performance. However, a ClassBridge will mark all objects of a
certain class as dirty and especially with Lazy connections, this can lead
to a flurry of unnecessary database calls and indexing actions. Also with
@Transient @Field this can occur when underlying Lazy connections are
initialized.
HSEARCH-1093 talks about a way to improve this by indicating to HSearch
which fields are actually managed by the Field (or ClassBridge) so as to
prevent unnecessary invocations. I'm curious about ideas on this. Could
this be an attribute, such as includePaths that overrides a default
@Field(managedFields={"user.id"})
@ClassBridge(managedFields={"user.id","description"})
or could it be an annotation
@DirtyAware(value={"user.id","description"})
12 years, 1 month
IRC meetings
by Steve Ebersole
We decided to put off the weekly meetings for the time being. At least
until we get the various codebases merged back together and start
pushing towards 5.0
--
steve(a)hibernate.org
http://hibernate.org
12 years, 1 month
JPA 2.1 / EntityManagerFactory#addNamedQuery
by Steve Ebersole
JPA 2.1 adds an ability to add/override a named query using a "compiled"
query object; javax.persistence.Query is the type passed in.
javax.persistence.Query just does not give access to the information
needed to create a named query definition (at the most basic you cannot
even get access to the original query string via
javax.persistence.Query). So this will have to be vendor specific;
meaning Hibernate will need to do instanceof type checks on the incoming
javax.persistence.Query object to make sure it is one we created (typed
as org.hibernate.ejb.HibernateQuery) so that we can access the
underlying org.hibernate.Query to get access to this information.
Unfortunately org.hibernate.Query also does not expose all the
information we need. The problem there is all the "query config"
setters that have no corresponding getters (things like setMaxResults,
setFirstResult, setCacheMode, etc). I am right now just adding the
needed getters to org.hibernate.Query. If other projects implement
org.hibernate.Query on their own, that obviously causes compatibility
issues. The other option is to instead create a "QueryImplementor"
contract that adds these new getter methods. I'd prefer not to do that,
if we don't have to though. So do other projects (hibernate search?,
ogm?) implement this interface?
--
steve(a)hibernate.org
http://hibernate.org
12 years, 1 month
