Re: [hibernate-dev] HHH-6726 LONG and LONG RAW column types in Oracle
by Łukasz Antoniak
Currently Oracle supports database versions from 10.1 to 11.2 [1]. LONG
and LONG RAW data types are deprecated since version 8 and 8i (released
before September 2000) [2]. Oracle keeps those column types only for
backward compatibility [3].
I tried the following scenario (Oracle 10gR2):
1. Create schema with "hibernate.hbm2ddl.auto" set to "create". The LONG
column is created.
2. Insert some data.
3. Modify Oracle dialect as Gail suggested. Avoid setting
"hibernate.hbm2ddl.auto".
4. Insert some data.
To my surprise the test actually passed :). However, I think that we
cannot guaranty the proper behavior in every situation.
As for performance, ImageType is extracted by calling
ResultSet.getBytes() method, which fetches all data in one call [4]. I
don't suppose a major performance difference when data is streamed in
another call. oracle.jdbc.driver.LongRawAccessor.getBytes also fetches
data by reading the stream.
The bug reading LONG column affects JDBC drivers since version 10.2.0.4.
I think that we have to choose between:
- changing Oracle10gDialect. Make a not about it in migration guide to
4.0 and update "5.2.2. Basic value types" chapter in Hibernate
documentation.
- introducing Oracle11gDialect. It can sound weird to access Oracle 10g
database with Oracle 11g dialect.
- disabling execution of Hibernate tests that fail because of this issue
with @SkipForDialect (and maybe develop another version of them with
CLOBs and BLOBs, @RequiresDialect). Hibernate is written correctly
according to "Default Mappings Between SQL Types and Java Types"
(referenced earlier by Gail) and this is more Oracle's JDBC
implementation issue. This option came to my mind, but it's weird :P.
I would vote for the first option.
Regards,
Lukasz Antoniak
[1]
http://www.oracle.com/us/support/library/lifetime-support-technology-0691...
(page 4)
[2]
http://download.oracle.com/docs/cd/A91202_01/901_doc/server.901/a90120/ch...
[3]
http://download.oracle.com/docs/cd/B28359_01/server.111/b28318/datatype.htm
[4] "Getting a LONG RAW Data Column with getBytes"
http://download.oracle.com/docs/cd/B19306_01/java.102/b14355/jstreams.htm
Strong Liu pisze:
> I think oracle 11g is the only one supported DB version by oracle, can we just introduce a new oracle dialect with suggested changes, and deprecate all other existed oracle dialects? this won't affects users app
>
> -----------
> Strong Liu <stliu(a)hibernate.org>
> http://hibernate.org
> http://github.com/stliu
>
> On Oct 15, 2011, at 11:14 AM, Scott Marlow wrote:
>
>> How does this impact existing applications? Would they have to convert
>> LONGs to CLOBs (and LONGRAWs to BLOBs) to keep the application working?
>>
>> As far as the advantage of CLOB over TEXT, if you read every character,
>> which one is really faster? I would expect TEXT to be a little faster,
>> since the server side will send the characters before they are asked
>> for. By faster, I mean from the application performance point of view. :)
>>
>> Could this be changed in a custom Oracle dialect? So new
>> applications/databases could perhaps use that and existing applications
>> might use LONGs a bit longer via the existing Oracle dialect.
>>
>> On 10/14/2011 09:22 PM, Gail Badner wrote:
>>> In [1], I am seeing the following type mappings:
>>>
>>> Column type: LONG -> java.sql.Types.LONGVARCHAR -> java.lang.String
>>> Column type: LONGRAW -> java.sql.Types.LONGVARBINARY -> byte[]
>>>
>>> org.hibernate.type.TextType is consistent with the mapping for LONG.
>>>
>>> org.hibernate.type.ImageType is consistent with the mapping for LONGRAW.
>>>
>>> From this standpoint, the current settings are appropriate.
>>>
>>> I understand there are restrictions when LONG and LONGRAW are used and I see from your other message that there is Oracle documentation for migrating to CLOB and BLOB.
>>>
>>> I agree that changing column type registration as follows (for Oracle only) should fix this:
>>> registerColumnType( Types.VARBINARY, 2000, "raw($l)" );
>>> registerColumnType( Types.VARBINARY, "blob" );
>>>
>>> registerColumnType( Types.LONGVARCHAR, "clob" );
>>> registerColumnType( Types.LONGVARBINARY, "blob" );
>>>
>>> registerColumnType( Types.VARCHAR, 4000, "varchar2($l char)" );
>>> registerColumnType( Types.VARCHAR, "clob" );
>>>
>>> Steve, what do you think? Is it too late to make this change for 4.0.0?
>>>
>>> [1] Table 11-1 of Oracle® Database JDBC Developer's Guide and Reference, 11g Release 1 (11.1) (http://download.oracle.com/docs/cd/B28359_01/java.111/b31224/datacc.htm#g...)
>>> [2] Hibernate Core Migration Guide for 3.5 (http://community.jboss.org/wiki/HibernateCoreMigrationGuide35)
>>> [3] Table 2-10 of Oracle® Database SQL Language Reference
>>> 11g Release 1 (11.1) (http://download.oracle.com/docs/cd/B28359_01/server.111/b28286/sql_elemen...)
>>>
>>> ----- Original Message -----
>>>> From: "Łukasz Antoniak"<lukasz.antoniak(a)gmail.com>
>>>> To: hibernate-dev(a)lists.jboss.org
>>>> Sent: Thursday, October 13, 2011 12:50:13 PM
>>>> Subject: [hibernate-dev] HHH-6726 LONG and LONG RAW column types in Oracle
>>>>
>>>> Welcome Community!
>>>>
>>>> I have just subscribed to the list and wanted to discuss HHH-6726
>>>> JIRA
>>>> issue.
>>>>
>>>> Gail Badner wrote
>>>> (http://lists.jboss.org/pipermail/hibernate-dev/2011-October/007208.html):
>>>> HHH-6726 (Oracle : map TextType to clob and ImageType to blob)
>>>> https://hibernate.onjira.com/browse/HHH-6726
>>>> There have been a number of issues opened since the change was made
>>>> to
>>>> map TextType (LONGVARCHAR) 'long' and ImageType (LONGVARBINARY) to
>>>> 'long
>>>> raw'. This change was already documented in the migration notes.
>>>> Should
>>>> the mapping for Oracle (only) be changed back to clob and blob?
>>>>
>>>> HHH-6726 is caused by an issue in Oracle JDBC driver (version
>>>> 10.2.0.4
>>>> and later). This bug appears when LONG or LONG RAW columns are
>>>> accessed
>>>> not as first or last while processing SQL statement.
>>>>
>>>> I have discussed the topic of mapping TextType to CLOB and ImageType
>>>> to
>>>> BLOB (only in Oracle dialect) with Strong Liu. Reasons for doing so:
>>>> - Oracle allows only one LONG / LONG RAW column per table. This might
>>>> be
>>>> the most important from Hibernate's perspective.
>>>> - LONG / LONG RAW - up to 2 GB, BLOB / CLOB - up to 4 GB.
>>>> - In PL/SQL using LOBs is more efficient (random access to data).
>>>> LONG
>>>> only sequential.
>>>> - LONG and LONG RAW are deprecated.
>>>>
>>>> What is your opinion?
>>>>
>>>> Regards,
>>>> Lukasz Antoniak
>>>> _______________________________________________
>>>> hibernate-dev mailing list
>>>> hibernate-dev(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
10 years
Hibernate ORM 4.2.0.CR1 Released
by Brett Meyer
http://in.relation.to/Bloggers/HibernateORM420CR1Released
Hibernate ORM 4.2.0.CR1 was just released. The full changelog can be viewed here: https://hibernate.onjira.com/secure/ReleaseNote.jspa?projectId=10031&vers...
This release included a few notable bug fixes and improvements:
- https://hibernate.onjira.com/browse/HHH-465 : "nulls first" and "nulls last" syntax in HQL ordering
- https://hibernate.onjira.com/browse/HHH-1917 : automatically delete orphaned JoinTable rows on a bulk delete affecting a Many-To-Many association
- https://hibernate.onjira.com/browse/HHH-2448 : deterministic column aliases, regardless of mapping ordering -- mainly affects clustering environments
- https://hibernate.onjira.com/browse/HHH-7797 : the logic handling unique columns and constraints was entirely re-written and improved
In addition, a handful of performance improvements went in. So far, we have seen dramatic improvements in JBoss benchmarking.
- https://hibernate.onjira.com/browse/HHH-7746 : additional batch loading algorithms (use "hibernate.batch_fetch_style" in your settings -- see the new Enum for choices)
- https://hibernate.onjira.com/browse/HHH-7872 : improves L2 caching of reference data (enable with "hibernate.cache.use_reference_entries")
- https://hibernate.onjira.com/browse/HHH-7902 : Originally, JDBC types (Connection, Statement, ResultSet, etc.) were wrapped with Java Proxies to introduce resource management, logging, etc. The proxying was shown to be a performance hotspot, so they were entirely removed. The functionality was replaced with a new set of internal contracts/helpers.
As usual, thank you to the community for all the support and hard work!
JBoss Nexus: https://repository.jboss.org/nexus/content/groups/public/org/hibernate
Maven Central: http://repo1.maven.org/maven2/org/hibernate/hibernate-core (should update in a couple of days)
SourceForge: https://sourceforge.net/projects/hibernate/files/hibernate4
Downloads: http://sourceforge.net/projects/hibernate/files/hibernate4/4.2.0.CR1/hibe... or http://sourceforge.net/projects/hibernate/files/hibernate4/4.2.0.CR1/hibe...
Brett Meyer
Red Hat Software Engineer, Hibernate
+1 260.349.5732
13 years
Hibernate ORM in OSGi
by Brett Meyer
HHH-7527 [1] will address Hibernate ORM in OSGi environments.
This task obviously has many design considerations and sub-tasks. Today, we created a Proposal Wiki [2] to start brainstorming many of the topics. We'd sincerely appreciate the communities involvement and feedback, especially with respect to identifying the many types of OSGi environment use cases.
The best way to help is to join the discussion on HHH-7527. Thanks!
[1] https://hibernate.onjira.com/browse/HHH-7527
[2] https://github.com/hibernate/hibernate-orm/wiki/Proposal:-OSGi
Brett Meyer
Red Hat Software Engineer, Hibernate
+1 260.349.5732
13 years
Re: [hibernate-dev] hibernate-dev Digest, Vol 79, Issue 21
by Marc Schipperheyn
Any word on the release of Hib ORM 4.1.10? I ran into an issue today that
forces me to go back 4.1.7
Vriendelijke groet,
Marc
M.Schipperheyn
<http://www.buscafreela.com.br>
MSW BV | Nova Zemblastraat 12-a, 1013 RK, Amsterdam | KvK: 02090184
skype: mschipperheyn | Twitter: mschipperheyn
Netherlands: m: +31 (0)6 218 03 003 | t: +31 (0)84 88 453 99
Brazil: m: +55 (0)11 99 44 6 3472
On Wed, Jan 30, 2013 at 3:00 PM, <hibernate-dev-request(a)lists.jboss.org>wrote:
> Send hibernate-dev mailing list submissions to
> hibernate-dev(a)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(a)lists.jboss.org
>
> You can reach the person managing the list at
> hibernate-dev-owner(a)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. Re: 4.2 branch (Steve Ebersole)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 30 Jan 2013 09:25:38 -0600
> From: Steve Ebersole <steve(a)hibernate.org>
> Subject: Re: [hibernate-dev] 4.2 branch
> To: Strong Liu <stliu(a)hibernate.org>
> Cc: Hibernate hibernate-dev <hibernate-dev(a)lists.jboss.org>
> Message-ID: <51093B72.9090900(a)hibernate.org>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> Yes, 4.2 is API complete at this time.
>
> Well we will do the CR today or tomorrow and see from there.
>
> On Tue 29 Jan 2013 09:29:45 AM CST, Strong Liu wrote:
> > On Tuesday, January 29, 2013 at 1:46 AM, Steve Ebersole wrote:
> >> As discussed in the last developer IRC meeting, the performance work we
> >> have been doing based on 4.1 will become its own base release (4.2)
> >> rather than continuing with 4.1 due to the fact that quite a few SPIs
> >> were re-worked in that effort. To that end, this afternoon I will
> >> rename the 4.1-perf branch to 4.2 and prepare an initial release
> >> 4.2.0.CR1.
> >
> > does this mean there will no more API change?
> > and do you have a release date in mind?
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev(a)lists.jboss.org <mailto:hibernate-dev@lists.jboss.org>
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
>
>
> ------------------------------
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
> End of hibernate-dev Digest, Vol 79, Issue 21
> *********************************************
>
13 years
4.2 branch
by Steve Ebersole
As discussed in the last developer IRC meeting, the performance work we
have been doing based on 4.1 will become its own base release (4.2)
rather than continuing with 4.1 due to the fact that quite a few SPIs
were re-worked in that effort. To that end, this afternoon I will
rename the 4.1-perf branch to 4.2 and prepare an initial release 4.2.0.CR1.
13 years
Re: [hibernate-dev] MetadataSourceProcessor and associations
by Gail Badner
Steve and Strong,
Thanks for the clarification. This helped a lot.
I have a couple more questions inline below.
----- Original Message -----
> From: "Steve Ebersole" <steven.ebersole(a)gmail.com>
> To: "Strong Liu" <stliu(a)hibernate.org>
> Cc: "Hibernate hibernate-dev" <hibernate-dev(a)lists.jboss.org>, "Gail Badner" <gbadner(a)redhat.com>
> Sent: Friday, January 25, 2013 9:45:26 AM
> Subject: Re: [hibernate-dev] MetadataSourceProcessor and associations
>
> ** DISCLAIMER : Its been a long time since I have been on the
> metamodel
> branch, so please excuse any misuse of class/interface names...
>
> Comments inline...
>
> On Thu 24 Jan 2013 11:21:22 PM CST, Strong Liu wrote:
> >
> > On Jan 24, 2013, at 1:26 PM, Gail Badner <gbadner(a)redhat.com
> > <mailto:gbadner@redhat.com>> wrote:
> >
> >>
> >> I am trying to figure out when we have all the necessary
> >> information
> >> to resolve everything required for associations.
> >>
> >> IIUC, sources are processed in the following order by default:
> >>
> >> 1) HBM sources extracted from MetadataSources passed to
> >> MetadataImpl
> >> constructor;
> >> 2) annotations sources extracted from MetadataSources passed to
> >> MetadataImpl constructor;
> >> 3) (annotations?) sources contributed by MetadataContributor
> >> service;
> >> 4) HBM sources from JaxbRoot objects produced by
> >> AdditionalJaxbRootProducer service.
>
>
> (1) and (2) are really the same thing: metadata sources explicitly
> handed to MetadataSources by the app (or contributed by any defined
> MetadataSourcesContributor impls). Aka, these are the known hbm.xml
> and
> annotation sources.
Can we assume that, after 1) and 2) execute, all information (in the form of hbm/annotations source) is available to resolve all existing associations?
If anything is left unresolved, should it be an exception?
>
> (3) the intent of MetadataContributor is for integrations to be able
> to
> provide additional new information to the Metadata object. Part of
> that
> could be contributing "mappings", however, if it were to contribute
> mappings it would be in the form of the new o.h.metamodel mapping
> classes already. Technically it could alter existing bindings.
Can we assume that after 3) is executed that all new and pre-existing (from 1) and 2)) associations in the metadata are (still) resolved? If so, should there be a check to ensure this is true?
>
> (4) the intent of this, as Strong pointed out, is for Envers use
> case.
> Basically it lets them read the already built Metamodel (fully
> resolved)
> and pass us back additional JAXB mapings (hbm.xml) representing their
> "version entities". To be completely honest, I always viewed this as
> a
> temporary hacky solution. IMO Envers should be producing full
> EntityBinding graphs. But this was the path of least resistance to
> get
> Envers up and running on this branch as quickly as possible.
>
Ah, I think I get it. If Envers provided EntityBinding graphs (instead of JAXB mappings), then Envers would contribute those bindings via the MetadataContributor service.
>
> >> The same Binder is used create bindings from 1) and 2). A
> >> different
> >> Binder is used for 4).
> TBH, I forget why different Binders were used.
Are Envers bindings completely unrelated (in terms of subclasses/superclasses) and unassociated (in terms of one-to-one/many-to-one/one-to-many/many-to-many associations) with entity bindings produced by 1), 2), and 3)?
If unrelated and unassociated with mappings provided by 1) and 2), then it makes sense that a separate Binder be used for 4).
>
> >> I am not familiar with how 3) and 4) are intended to be used.
> Answered above
> >>
> >> Does 3) make "contributions" directly to the MetadataImpl? What
> >> kind
> >> of contributions are they?
> Answered above. Could technically contribute any of the things
> exposed
> on the MetadataImplentor contract.
> >>
> >> Can 3) and 4) result in added or changed EntityBindings?
> Well it would be odd for (4) to add (or change for that matter)
> EntityBindings. (4) is all about creating additional "entity
> bindings"
> but by way of contributing back new JAXB bindings to process. (3)
> Could
> certainly add/change bindings.
>
> >
> >
> > IIUC, 3) is for extensions that want to create / modify metamodel (
> > binding / relational / domain ) directly
> > 4) is for extensions what want to contribute hbm sources and let
> > the
> > Binder to do the binding stuff
> >
> >
> > take envers as an example, for each entity with @Audit, envers
> > creates
> > an internal entity and associate it with the original one.
> >
> > the current impl ( with old metamodel )
> >
> > 1. new Configuration -- mapping process
> > 2. building SF
> > 2.1 calling Integrator, which envers come into play, it just review
> > all entities and find out the audit entities, then create hbm xml
> > documents for each one, add these hbm documents into Configuration
> > and
> > call the buildMappings again
> > 2.2 SF cons process continues, this time, the persister factory
> > sees the new Configuration processed mappings ( envers created hbm
> > included)
> >
> > so, to achieve this in the new metamodel design, extensions can
> > choose
> > which way is easier :
> >
> > 1. the same way as envers currently does (creating hbm in memory
> > and
> > ask hibernate to do the binding stuff) -- 4)
> > 2. create/change metamodel directly -- 3)
> >
> >
> >>
> >>
> >> Regards,
> >> Gail
> >>
> >> ----- Original Message -----
> >>>
> >>> From: "Steve Ebersole" <steven.ebersole(a)gmail.com
> >>> <mailto:steven.ebersole@gmail.com>>
> >>> To: "Gail Badner" <gbadner(a)redhat.com
> >>> <mailto:gbadner@redhat.com>>
> >>> Cc: "Hibernate hibernate-dev" <hibernate-dev(a)lists.jboss.org
> >>> <mailto:hibernate-dev@lists.jboss.org>>
> >>> Sent: Wednesday, January 23, 2013 11:16:23 AM
> >>> Subject: Re: [hibernate-dev] MetadataSourceProcessor and
> >>> associations
> >>>
> >>> What you mention is in fact possible.
> >>>
> >>> And I have never been very hopeful about the "chasing"
> >>> approach...
> >>>
> >>>
> >>> On Wed 23 Jan 2013 01:13:48 PM CST, Gail Badner wrote:
> >>>>
> >>>> Is it possible for an entity containing one side of an
> >>>> association
> >>>> be mapped using annotations and the entity containing the
> >>>> opposite
> >>>> side of the association be mapped using an hbm mapping?
> >>>>
> >>>> For example, suppose Order has annotations:
> >>>>
> >>>> @OneToMany( mappedby="order" )
> >>>> List<OrderLine> Order.orderLines
> >>>>
> >>>> OrderLine is mapped using hbm.xml with:
> >>>>
> >>>> <many-to-one name="order"/>
> >>>>
> >>>> If annotations are processed first, then, IIUC, when
> >>>> Order.orderLines is processed, the mapping for OrderLine won't
> >>>> be
> >>>> found (via chasing) because the
> >>>> AnnotationMetadataSourceProcessorImpl does not have the source
> >>>> for
> >>>> the OrderLine mapping. As a result, the OrderLine EntityBinding
> >>>> will not be able to be built until
> >>>> HbmMetadataSourceProcessorImpl
> >>>> is processed.
> >>>>
> >>>> If so, this poses a fundamental problem with entity "chasing" as
> >>>> it
> >>>> is implemented now, since the associated entity would not be
> >>>> processed by the same MetadataSourceProcessor.
> >>>>
> >>>> Am I missing something here?
> >>>>
> >>>> Thanks,
> >>>> Gail
> >>>> _______________________________________________
> >>>> hibernate-dev mailing list
> >>>> hibernate-dev(a)lists.jboss.org
> >>>> <mailto:hibernate-dev@lists.jboss.org>
> >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>>
> >>>
> >>
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev(a)lists.jboss.org
> >> <mailto:hibernate-dev@lists.jboss.org>
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> >
> > -------------------------
> > Best Regards,
> >
> > Strong Liu <stliu at hibernate.org <http://hibernate.org/>>
> > http://about.me/stliu/bio
>
13 years
Re: [hibernate-dev] MetadataSourceProcessor and associations
by Gail Badner
I am trying to figure out when we have all the necessary information to resolve everything required for associations.
IIUC, sources are processed in the following order by default:
1) HBM sources extracted from MetadataSources passed to MetadataImpl constructor;
2) annotations sources extracted from MetadataSources passed to MetadataImpl constructor;
3) (annotations?) sources contributed by MetadataContributor service;
4) HBM sources from JaxbRoot objects produced by AdditionalJaxbRootProducer service.
The same Binder is used create bindings from 1) and 2). A different Binder is used for 4).
I am not familiar with how 3) and 4) are intended to be used.
Does 3) make "contributions" directly to the MetadataImpl? What kind of contributions are they?
Can 3) and 4) result in added or changed EntityBindings?
Regards,
Gail
----- Original Message -----
> From: "Steve Ebersole" <steven.ebersole(a)gmail.com>
> To: "Gail Badner" <gbadner(a)redhat.com>
> Cc: "Hibernate hibernate-dev" <hibernate-dev(a)lists.jboss.org>
> Sent: Wednesday, January 23, 2013 11:16:23 AM
> Subject: Re: [hibernate-dev] MetadataSourceProcessor and associations
>
> What you mention is in fact possible.
>
> And I have never been very hopeful about the "chasing" approach...
>
>
> On Wed 23 Jan 2013 01:13:48 PM CST, Gail Badner wrote:
> > Is it possible for an entity containing one side of an association
> > be mapped using annotations and the entity containing the opposite
> > side of the association be mapped using an hbm mapping?
> >
> > For example, suppose Order has annotations:
> >
> > @OneToMany( mappedby="order" )
> > List<OrderLine> Order.orderLines
> >
> > OrderLine is mapped using hbm.xml with:
> >
> > <many-to-one name="order"/>
> >
> > If annotations are processed first, then, IIUC, when
> > Order.orderLines is processed, the mapping for OrderLine won't be
> > found (via chasing) because the
> > AnnotationMetadataSourceProcessorImpl does not have the source for
> > the OrderLine mapping. As a result, the OrderLine EntityBinding
> > will not be able to be built until HbmMetadataSourceProcessorImpl
> > is processed.
> >
> > If so, this poses a fundamental problem with entity "chasing" as it
> > is implemented now, since the associated entity would not be
> > processed by the same MetadataSourceProcessor.
> >
> > Am I missing something here?
> >
> > Thanks,
> > Gail
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
13 years
MetadataSourceProcessor and associations
by Gail Badner
Is it possible for an entity containing one side of an association be mapped using annotations and the entity containing the opposite side of the association be mapped using an hbm mapping?
For example, suppose Order has annotations:
@OneToMany( mappedby="order" )
List<OrderLine> Order.orderLines
OrderLine is mapped using hbm.xml with:
<many-to-one name="order"/>
If annotations are processed first, then, IIUC, when Order.orderLines is processed, the mapping for OrderLine won't be found (via chasing) because the AnnotationMetadataSourceProcessorImpl does not have the source for the OrderLine mapping. As a result, the OrderLine EntityBinding will not be able to be built until HbmMetadataSourceProcessorImpl is processed.
If so, this poses a fundamental problem with entity "chasing" as it is implemented now, since the associated entity would not be processed by the same MetadataSourceProcessor.
Am I missing something here?
Thanks,
Gail
13 years
