hibernate-devel — development

[Hibernate] descriptions on fields and tables using hibernate

[Mark V. <ma...@ve...>]

Hello all!

I'm new to this maling list and to hibernate so please bear with me (meanin=
g=20
you can flame me but not roast me...). And now to business...

I noticed that the "@Column" annotation does not have a "description"=20
attribute. This is most saddening since such a description could be used in=
=20
many ways. for example:

1. The description could be used for documenting the database structure usi=
ng=20
hibernate-tools.
2. The description could be pushed out to the database itself using "CREATE=
=20
table () description "This is a table to store customers" or the like. Some=
=20
database support this and will actually store the description for you which=
=20
makes it easier to use the database even if you don't have documentation fo=
r=20
it.
3. Many other ways of which I hadn't tought about (probably the most=20
interesting ones).

A few questions:
1. Is such a feature in the works ? Even if this feature will only be=20
supported on some of database engines the documentation could state so and =
it=20
would still be useful...
2. If a feature like this is not in the works would you like me to implemen=
t=20
it ? I'm a java developer and have had my own database persistency system=20
written in perl so I can handle a task like this. I would be able to do it=
=20
only for mysql tough because that is all I have now (maybe for postgresql=20
later on). Other people will need to implement it for other database driver=
s.
3. What about translations of such descriptions to other locales ? I need t=
o=20
think about that some more and your ideas are welcome...
4. I would assume that if hibernate annotations would support it then first=
=20
the change should go in through hibernate core, then support should be adde=
d=20
in the XML files, then at the annotation level and finally at the tools=20
level. Am I right ? BTW: I noticed that <hbm2doc> already creates html page=
s=20
with "description" on them but the descriptions are empty.

Cheers,
	Mark

[Hibernate] descriptions on fields and tables using hibernate

[Mark V. <ma...@ve...>]

Hello all!

I'm new to this maling list and to hibernate so please bear with me (meanin=
g=20
you can flame me but not roast me...). And now to business...

I noticed that the "@Column" annotation does not have a "description"=20
attribute. This is most saddening since such a description could be used in=
=20
many ways. for example:

1. The description could be used for documenting the database structure usi=
ng=20
hibernate-tools.
2. The description could be pushed out to the database itself using "CREATE=
=20
table () description "This is a table to store customers" or the like. Some=
=20
database support this and will actually store the description for you which=
=20
makes it easier to use the database even if you don't have documentation fo=
r=20
it.
3. Many other ways of which I hadn't tought about (probably the most=20
interesting ones).

A few questions:
1. Is such a feature in the works ? Even if this feature will only be=20
supported on some of database engines the documentation could state so and =
it=20
would still be useful...
2. If a feature like this is not in the works would you like me to implemen=
t=20
it ? I'm a java developer and have had my own database persistency system=20
written in perl so I can handle a task like this. I would be able to do it=
=20
only for mysql tough because that is all I have now (maybe for postgresql=20
later on). Other people will need to implement it for other database driver=
s.
3. What about translations of such descriptions to other locales ? I need t=
o=20
think about that some more and your ideas are welcome...
4. I would assume that if hibernate annotations would support it then first=
=20
the change should go in through hibernate core, then support should be adde=
d=20
in the XML files, then at the annotation level and finally at the tools=20
level. Am I right ? BTW: I noticed that <hbm2doc> already creates html page=
s=20
with "description" on them but the descriptions are empty.

Cheers,
	Mark

[Hibernate] Good day

[<jwb...@ta...>]

The message contains Unicode characters and has been sent as a binary attachment.

[Hibernate] zxczcz

[Minatee P. <min...@da...>]

Disclaimer: The information contained in this e-mail and attachments if any are privileged and confidential and are intended for the individual(s) or entity(ies) named in this e-mail. If the reader or recipient is not the intended recipient, or employee or agent responsible for delivering to the intended recipient, you are hereby notified that dissemination, distribution or copying of this communication or attachments thereof is strictly prohibited. IF YOU RECEIVE this communication in error, please immediately notify the sender and return the original message.

[Hibernate] OT: Invitation to participate in research project

[Ben A. <ben...@st...>]

Hello there

I would greatly appreciate a small amount of your time to assist with
my doctoral research at The University of Newcastle. The research
concerns open source licensing and we're seeking developers working on
Java projects. The research is supervised, ethics-approved, anonymous
and results will be freely available. Participation will also provide a
custom licensing report for your project. To learn more, please visit:

   http://licensing-research.newcastle.edu.au

Thanks for reading this email, and I hope you'll consider participating.

Best regards
Ben Alex

(My apologies for being off-topic; this list will not be emailed again)

[Hibernate] NoClassDefFoundError

[Gordon, C. T <Chr...@bo...>]

I'm still looking into the code, but I have been for a while without a
whole lot of success, so I'll throw this out there in case someone else
has ran into this and conquered it.

I am getting a no class def found error.  Here is the stack trace.
Again, there is a good chance this is an issue with our code, but I'm
wondering if I just have an old version of a file or a misplaced file or
something like that

Thanks,

Chris

java.lang.NoClassDefFoundError
        at
org.hibernate.event.def.AbstractSaveEventListener.cascadeBeforeSave(Abst
ractSaveEventListener.java:431)
        at
org.hibernate.event.def.AbstractSaveEventListener.performSaveOrReplicate
(AbstractSaveEventListener.java:265)
        at
org.hibernate.event.def.AbstractSaveEventListener.performSave(AbstractSa
veEventListener.java:181)
        at
org.hibernate.event.def.AbstractSaveEventListener.saveWithGeneratedId(Ab
stractSaveEventListener.java:121)
        at
org.hibernate.event.def.DefaultSaveOrUpdateEventListener.saveWithGenerat
edOrRequestedId(DefaultSaveOrUpdateEventListener.java:187)
        at
org.hibernate.event.def.DefaultSaveEventListener.saveWithGeneratedOrRequ
estedId(DefaultSaveEventListener.java:33)
        at
org.hibernate.event.def.DefaultSaveOrUpdateEventListener.entityIsTransie
nt(DefaultSaveOrUpdateEventListener.java:172)
        at
org.hibernate.event.def.DefaultSaveEventListener.performSaveOrUpdate(Def
aultSaveEventListener.java:27)
        at
org.hibernate.event.def.DefaultSaveOrUpdateEventListener.onSaveOrUpdate(
DefaultSaveOrUpdateEventListener.java:70)
        at org.hibernate.impl.SessionImpl.fireSave(SessionImpl.java:535)
        at org.hibernate.impl.SessionImpl.save(SessionImpl.java:523)
        at org.hibernate.impl.SessionImpl.save(SessionImpl.java:519)
        at
com.caci.pdi.core.PersistentObjectFactory.create(PersistentObjectFactory
.java:144)
        at
com.caci.pdi.core.DocManager.createJdbcValueObject(DocManager.java:525)
        at
com.caci.pdi.core.DocManager.createValueObject(DocManager.java:750)
        at com.caci.pdi.core.Manager.saveValueObject(Manager.java:873)
        at com.caci.pdi.core.DocManager.saveObject(DocManager.java:1010)
        at
com.caci.pdi.core.persist.acquisition.purchaseorder.PurchaseOrderManager
.saveObject(PurchaseOrderManager.java:793)
        at com.caci.pdi.core.Manager.performSave(Manager.java:692)
        at com.caci.pdi.core.Manager.save(Manager.java:596)
        at
com.caci.core.momapi.client.InsertHelper.insertVOFromInputObjBean(Insert
Helper.java:776)
        at
com.caci.core.momapi.client.InsertHelper.createObjectBean(InsertHelper.j
ava:706)
        at
com.caci.core.momapi.client.BeanToPdiImpl.perform11(BeanToPdiImpl.java:5
28)
        at
com.ams.adapter.momapi.services.Perform.objectPerform11(Perform.java:114
)
        at
com.ams.adapter.momapi.services.Perform.objectPerform(Perform.java:99)
        at
com.ams.adapter.momapi.services.Perform.execute(Perform.java:61)
        at
com.wm.adk.cci.interaction.WmInteraction.execute(WmInteraction.java:76)
        at
com.wm.pkg.art.ns.AdapterServiceNode.invokeService(AdapterServiceNode.ja
va:338)
        at
com.wm.pkg.art.ns.ARTNSService.baseInvoke(ARTNSService.java:54)
        at
com.wm.app.b2b.server.invoke.InvokeManager.process(InvokeManager.java:61
2)
        at
com.wm.app.b2b.server.invoke.StatisticsProcessor.process(StatisticsProce
ssor.java:44)
        at
com.wm.app.b2b.server.invoke.ServiceCompletionImpl.process(ServiceComple
tionImpl.java:235)
        at
com.wm.app.b2b.server.invoke.ValidateProcessor.process(ValidateProcessor
.java:49)
        at com.wm.app.b2b.server.ACLManager.process(ACLManager.java:198)
        at
com.wm.app.b2b.server.invoke.DispatchProcessor.process(DispatchProcessor
.java:39)
        at
com.wm.app.b2b.server.AuditLogManager.process(AuditLogManager.java:411)
        at
com.wm.app.b2b.server.invoke.InvokeManager.invoke(InvokeManager.java:521
)
        at
com.wm.app.b2b.server.invoke.InvokeManager.invoke(InvokeManager.java:369
)
        at
com.wm.app.b2b.server.ServiceManager.invoke(ServiceManager.java:246)
        at
com.wm.app.b2b.server.BaseService.invoke(BaseService.java:168)
        at com.wm.lang.flow.FlowInvoke.invoke(FlowInvoke.java:324)
        at com.wm.lang.flow.FlowState.invokeNode(FlowState.java:581)
        at com.wm.lang.flow.FlowState.step(FlowState.java:438)
        at com.wm.lang.flow.FlowState.invoke(FlowState.java:403)
        at
com.wm.app.b2b.server.FlowSvcImpl.baseInvoke(FlowSvcImpl.java:982)
        at
com.wm.app.b2b.server.invoke.InvokeManager.process(InvokeManager.java:61
2)
        at
com.wm.app.b2b.server.invoke.StatisticsProcessor.process(StatisticsProce
ssor.java:44)
        at
com.wm.app.b2b.server.invoke.ServiceCompletionImpl.process(ServiceComple
tionImpl.java:235)
        at
com.wm.app.b2b.server.invoke.ValidateProcessor.process(ValidateProcessor
.java:49)
        at com.wm.app.b2b.server.ACLManager.process(ACLManager.java:198)
        at
com.wm.app.b2b.server.invoke.DispatchProcessor.process(DispatchProcessor
.java:39)
        at
com.wm.app.b2b.server.AuditLogManager.process(AuditLogManager.java:411)
        at
com.wm.app.b2b.server.invoke.InvokeManager.invoke(InvokeManager.java:521
)
        at
com.wm.app.b2b.server.invoke.InvokeManager.invoke(InvokeManager.java:369
)
        at
com.wm.app.b2b.server.ServiceManager.invoke(ServiceManager.java:246)
        at
com.wm.app.b2b.server.comm.DefaultServerRequestHandler.handleMessage(Def
aultServerRequestHandler.java:129)
        at
com.wm.app.b2b.server.HTTPMessageHandler.process(HTTPMessageHandler.java
:168)
        at com.wm.app.b2b.server.Dispatch.run(Dispatch.java:312)
        at com.wm.util.pool.PooledThread.run(PooledThread.java:105)
        at java.lang.Thread.run(Thread.java:534)

[Hibernate] Many-to-one relationship where parent class is same as child

[javed m. <ja...@gm...>]

Hibernate version: 3.1.3

Name and version of the database you are using: Oracle 10


Hi I have a question regarding how many-to-one relationship should be
defined where the parent class is same type as the child class.

--------------------
Person table
---------------------
- name
- surname
- national_id - (PKey)
- passport_id - (PKey)
- address
- parent_national_id - (Parent -PK)
- parent_passport_id - (Parent -PK)

------------------------

Take the case of the table above where a person is defined within a person
table and has a composite key national_id and passport_id.

Now I want to get the Parent for that person which has composite key
parent_national_id and parent_passport_id defined within the Person table.

How would the hibernate mapping configuration would look like.

When I do a getParent on a Person object i would want to get its parent of
type Person.

Re: [Hibernate] java.lang.OutOfMemoryError: PermGen space

[Jeoff W. <jeo...@gm...>]

My bad. To turn off cglib you need to set it as a system-level property.
java -Dhibernate.cglib.use_reflection_optimizer=false

http://www.hibernate.org/hib_docs/v3/reference/en/html/session-configuration.html#configuration-misc-properties
hibernate.cglib.use_reflection_optimizer=false
Enables/disables use of CGLIB instead of runtime reflection (System-level
property). Reflection can sometimes be useful when troubleshooting, note
that Hibernate always requires CGLIB even if you turn off the optimizer. You
can not set this property in hibernate.cfg.xml.

On 6/5/07, Jeoff Wilks <jeo...@gm...> wrote:
>
>
> http://docs.jboss.org/jbossas/jboss4guide/r2/html/ch13.html#ch13.config.table
> hibernate.cglib.use_reflection_optimizer=false
>
> Set this in hibernate.properties, as a java system property, or by calling
> Configuration#setProperty() directly.
>
> You can postpone the problem a bit using the java command flag
> -XX:MaxPermSize.
> e.g. from http://www.caucho.com/support/resin-interest/0512/0022.html
> > Of course we can increase the PermGen size by adding -XX:MaxPermSize to
> > the command line. Though this only increases N and pushes the problem
> > further away, but it will always occur eventually.
>
> On 6/5/07, John Mitchell < mit...@gm...> wrote:
> >
> > Jeff,
> >
> > Thanks for the info!  How do I turn off CGLIB?
> >
> > Thanks,
> >
> > John Mitchell
> >
> > On 6/4/07, Jeoff Wilks < jeo...@gm...> wrote:
> > >
> > > Every time the CGLIB Enhancer generates a new class, that generated
> > > class jumps straight to the PermGen (permanent generation) of your java
> > > heap. CGLIB Enhancers are faster in terms of performance, but more dangerous
> > > in terms of memory consumption. (I ran into this same problem with another
> > > product that uses CGLIB.)
> > >
> > > Try turning off CGLIB and just have hibernate use reflection. If that
> > > solves the problem, then you can always work on tuning CGLIB later.
> > >
> > >
> > > On 6/4/07, John Mitchell <mit...@gm...> wrote:
> > >
> > > >  Hi,
> > > >
> > > > I have been having to restart Apache Tomcat as frequently as once a
> > > > day and I suspect the problem is related to hibernate.
> > > >
> > > > I have attached an error log from apache tomcat:
> > > >
> > > > I get the following error below
> > > >
> > > > ERROR BasicLazyInitializer:105 - CBLIB Enhancement failed:
> > > > com.insequence.gv.ProductOrder
> > > >
> > > > then further down the log file
> > > >
> > > > java.lang.OutOfMemoryError: PermGen space
> > > >
> > > > I also noticed towards the beginning of the log file
> > > >
> > > > 13:26:55,625  INFO DriverManagerConnectionProvider:41 - Using
> > > > Hibernate built-in connection pool (not for production use!)
> > > > 13:26:55,640  INFO DriverManagerConnectionProvider:42 - Hibernate
> > > > connection pool size: 1
> > > >
> > > > Do I need to switch to a different connection pool and if so what?
> > > > Should I change the "Hibernate connection pool size: 1"  to a number
> > > > higher than 1 for better stability and if so what number?
> > > >
> > > > Thanks,
> > > >
> > > > --
> > > > John J. Mitchell
> > > >
> > > > -------------------------------------------------------------------------
> > > > This SF.net email is sponsored by DB2 Express
> > > > Download DB2 Express C - the FREE version of DB2 express and take
> > > > control of your XML. No limits. Just data. Click to get it now.
> > > > http://sourceforge.net/powerbar/db2/
> > > > _______________________________________________
> > > > hibernate-devel mailing list
> > > > hib...@li...
> > > > https://lists.sourceforge.net/lists/listinfo/hibernate-devel
> > > >
> > > >
> > > >
> > >
> >
> >
> > --
> > John J. Mitchell
>
>
>

Re: [Hibernate] java.lang.OutOfMemoryError: PermGen space

[Jeoff W. <jeo...@gm...>]

http://docs.jboss.org/jbossas/jboss4guide/r2/html/ch13.html#ch13.config.table
hibernate.cglib.use_reflection_optimizer=false

Set this in hibernate.properties, as a java system property, or by calling
Configuration#setProperty() directly.

You can postpone the problem a bit using the java command flag
-XX:MaxPermSize.
e.g. from http://www.caucho.com/support/resin-interest/0512/0022.html
> Of course we can increase the PermGen size by adding -XX:MaxPermSize to
> the command line. Though this only increases N and pushes the problem
> further away, but it will always occur eventually.

On 6/5/07, John Mitchell <mit...@gm...> wrote:
>
> Jeff,
>
> Thanks for the info!  How do I turn off CGLIB?
>
> Thanks,
>
> John Mitchell
>
> On 6/4/07, Jeoff Wilks < jeo...@gm...> wrote:
> >
> > Every time the CGLIB Enhancer generates a new class, that generated
> > class jumps straight to the PermGen (permanent generation) of your java
> > heap. CGLIB Enhancers are faster in terms of performance, but more dangerous
> > in terms of memory consumption. (I ran into this same problem with another
> > product that uses CGLIB.)
> >
> > Try turning off CGLIB and just have hibernate use reflection. If that
> > solves the problem, then you can always work on tuning CGLIB later.
> >
> >
> > On 6/4/07, John Mitchell <mit...@gm...> wrote:
> >
> > >  Hi,
> > >
> > > I have been having to restart Apache Tomcat as frequently as once a
> > > day and I suspect the problem is related to hibernate.
> > >
> > > I have attached an error log from apache tomcat:
> > >
> > > I get the following error below
> > >
> > > ERROR BasicLazyInitializer:105 - CBLIB Enhancement failed:
> > > com.insequence.gv.ProductOrder
> > >
> > > then further down the log file
> > >
> > > java.lang.OutOfMemoryError: PermGen space
> > >
> > > I also noticed towards the beginning of the log file
> > >
> > > 13:26:55,625  INFO DriverManagerConnectionProvider:41 - Using
> > > Hibernate built-in connection pool (not for production use!)
> > > 13:26:55,640  INFO DriverManagerConnectionProvider:42 - Hibernate
> > > connection pool size: 1
> > >
> > > Do I need to switch to a different connection pool and if so what?
> > > Should I change the "Hibernate connection pool size: 1"  to a number
> > > higher than 1 for better stability and if so what number?
> > >
> > > Thanks,
> > >
> > > --
> > > John J. Mitchell
> > >
> > > -------------------------------------------------------------------------
> > > This SF.net email is sponsored by DB2 Express
> > > Download DB2 Express C - the FREE version of DB2 express and take
> > > control of your XML. No limits. Just data. Click to get it now.
> > > http://sourceforge.net/powerbar/db2/
> > > _______________________________________________
> > > hibernate-devel mailing list
> > > hib...@li...
> > > https://lists.sourceforge.net/lists/listinfo/hibernate-devel
> > >
> > >
> > >
> >
>
>
> --
> John J. Mitchell

Re: [Hibernate] java.lang.OutOfMemoryError: PermGen space

[John M. <mit...@gm...>]

Jeff,

Thanks for the info!  How do I turn off CGLIB?

Thanks,

John Mitchell

On 6/4/07, Jeoff Wilks <jeo...@gm...> wrote:
>
> Every time the CGLIB Enhancer generates a new class, that generated class
> jumps straight to the PermGen (permanent generation) of your java heap.
> CGLIB Enhancers are faster in terms of performance, but more dangerous in
> terms of memory consumption. (I ran into this same problem with another
> product that uses CGLIB.)
>
> Try turning off CGLIB and just have hibernate use reflection. If that
> solves the problem, then you can always work on tuning CGLIB later.
>
>
> On 6/4/07, John Mitchell <mit...@gm...> wrote:
>
> > Hi,
> >
> > I have been having to restart Apache Tomcat as frequently as once a day
> > and I suspect the problem is related to hibernate.
> >
> > I have attached an error log from apache tomcat:
> >
> > I get the following error below
> >
> > ERROR BasicLazyInitializer:105 - CBLIB Enhancement failed:
> > com.insequence.gv.ProductOrder
> >
> > then further down the log file
> >
> > java.lang.OutOfMemoryError: PermGen space
> >
> > I also noticed towards the beginning of the log file
> >
> > 13:26:55,625  INFO DriverManagerConnectionProvider:41 - Using Hibernate
> > built-in connection pool (not for production use!)
> > 13:26:55,640  INFO DriverManagerConnectionProvider:42 - Hibernate
> > connection pool size: 1
> >
> > Do I need to switch to a different connection pool and if so what?
> > Should I change the "Hibernate connection pool size: 1"  to a number
> > higher than 1 for better stability and if so what number?
> >
> > Thanks,
> >
> > --
> > John J. Mitchell
> >
> > -------------------------------------------------------------------------
> > This SF.net email is sponsored by DB2 Express
> > Download DB2 Express C - the FREE version of DB2 express and take
> > control of your XML. No limits. Just data. Click to get it now.
> > http://sourceforge.net/powerbar/db2/
> > _______________________________________________
> > hibernate-devel mailing list
> > hib...@li...
> > https://lists.sourceforge.net/lists/listinfo/hibernate-devel
> >
> >
> >
>


-- 
John J. Mitchell

Re: [Hibernate] java.lang.OutOfMemoryError: PermGen space

[Jeoff W. <jeo...@gm...>]

Every time the CGLIB Enhancer generates a new class, that generated class
jumps straight to the PermGen (permanent generation) of your java heap.
CGLIB Enhancers are faster in terms of performance, but more dangerous in
terms of memory consumption. (I ran into this same problem with another
product that uses CGLIB.)

Try turning off CGLIB and just have hibernate use reflection. If that solves
the problem, then you can always work on tuning CGLIB later.


On 6/4/07, John Mitchell <mit...@gm...> wrote:
>
> Hi,
>
> I have been having to restart Apache Tomcat as frequently as once a day
> and I suspect the problem is related to hibernate.
>
> I have attached an error log from apache tomcat:
>
> I get the following error below
>
> ERROR BasicLazyInitializer:105 - CBLIB Enhancement failed:
> com.insequence.gv.ProductOrder
>
> then further down the log file
>
> java.lang.OutOfMemoryError: PermGen space
>
> I also noticed towards the beginning of the log file
>
> 13:26:55,625  INFO DriverManagerConnectionProvider:41 - Using Hibernate
> built-in connection pool (not for production use!)
> 13:26:55,640  INFO DriverManagerConnectionProvider:42 - Hibernate
> connection pool size: 1
>
> Do I need to switch to a different connection pool and if so what?
> Should I change the "Hibernate connection pool size: 1"  to a number
> higher than 1 for better stability and if so what number?
>
> Thanks,
>
> --
> John J. Mitchell
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> hibernate-devel mailing list
> hib...@li...
> https://lists.sourceforge.net/lists/listinfo/hibernate-devel
>
>
>

[Hibernate] java.lang.OutOfMemoryError: PermGen space

[John M. <mit...@gm...>]

MTM6MjY6NTUsNjA5ICBJTkZPIEhibUJpbmRlcjozMTEgLSBNYXBwaW5nIGNsYXNzOiBjb20uaW5z
ZXF1ZW5jZS5ndi5Qcm9kdWN0IC0+IGd2X3N1cHBsaWVycw0KMTM6MjY6NTUsNjA5ICBJTkZPIENv
bmZpZ3VyYXRpb246NDYwIC0gUmVhZGluZyBtYXBwaW5ncyBmcm9tIHJlc291cmNlOiBQcm9kdWN0
T3JkZXIuaGJtLnhtbA0KMTM6MjY6NTUsNjA5ICBJTkZPIEhibUJpbmRlcjozMTEgLSBNYXBwaW5n
IGNsYXNzOiBjb20uaW5zZXF1ZW5jZS5ndi5Qcm9kdWN0T3JkZXIgLT4gZ3ZfcHJvZHVjdF9vcmRl
cg0KMTM6MjY6NTUsNjA5ICBJTkZPIENvbmZpZ3VyYXRpb246NDYwIC0gUmVhZGluZyBtYXBwaW5n
cyBmcm9tIHJlc291cmNlOiBTdXBwbGllckN1c3RvbWVyQWNjZXNzLmhibS54bWwNCjEzOjI2OjU1
LDYyNSAgSU5GTyBIYm1CaW5kZXI6MzExIC0gTWFwcGluZyBjbGFzczogY29tLmluc2VxdWVuY2Uu
Z3YuU3VwcGxpZXJDdXN0b21lckFjY2VzcyAtPiBndl9zdXBwbGllcl9jdXN0b21lcl9hY2Nlc3MN
CjEzOjI2OjU1LDYyNSAgSU5GTyBDb25maWd1cmF0aW9uOjQ2MCAtIFJlYWRpbmcgbWFwcGluZ3Mg
ZnJvbSByZXNvdXJjZTogVXNlci5oYm0ueG1sDQoxMzoyNjo1NSw2MjUgIElORk8gSGJtQmluZGVy
OjMxMSAtIE1hcHBpbmcgY2xhc3M6IGNvbS5pbnNlcXVlbmNlLmd2LlVzZXIgLT4gZ3ZfdXNlcg0K
MTM6MjY6NTUsNjI1ICBJTkZPIENvbmZpZ3VyYXRpb246NDYwIC0gUmVhZGluZyBtYXBwaW5ncyBm
cm9tIHJlc291cmNlOiBTdHJ1Y3R1cmUuaGJtLnhtbA0KMTM6MjY6NTUsNjI1ICBJTkZPIEhibUJp
bmRlcjozMTEgLSBNYXBwaW5nIGNsYXNzOiBjb20uaW5zZXF1ZW5jZS5ndi5TdHJ1Y3R1cmUgLT4g
Z3Zfc3RydWN0dXJlDQoxMzoyNjo1NSw2MjUgIElORk8gQ29uZmlndXJhdGlvbjoxMzUwIC0gQ29u
ZmlndXJlZCBTZXNzaW9uRmFjdG9yeTogbnVsbA0KMTM6MjY6NTUsNjI1ICBJTkZPIENvbmZpZ3Vy
YXRpb246OTk2IC0gcHJvY2Vzc2luZyBleHRlbmRzIHF1ZXVlDQoxMzoyNjo1NSw2MjUgIElORk8g
Q29uZmlndXJhdGlvbjoxMDAwIC0gcHJvY2Vzc2luZyBjb2xsZWN0aW9uIG1hcHBpbmdzDQoxMzoy
Njo1NSw2MjUgIElORk8gQ29uZmlndXJhdGlvbjoxMDA5IC0gcHJvY2Vzc2luZyBhc3NvY2lhdGlv
biBwcm9wZXJ0eSByZWZlcmVuY2VzDQoxMzoyNjo1NSw2MjUgIElORk8gQ29uZmlndXJhdGlvbjox
MDMxIC0gcHJvY2Vzc2luZyBmb3JlaWduIGtleSBjb25zdHJhaW50cw0KMTM6MjY6NTUsNjI1ICBJ
TkZPIERyaXZlck1hbmFnZXJDb25uZWN0aW9uUHJvdmlkZXI6NDEgLSBVc2luZyBIaWJlcm5hdGUg
YnVpbHQtaW4gY29ubmVjdGlvbiBwb29sIChub3QgZm9yIHByb2R1Y3Rpb24gdXNlISkNCjEzOjI2
OjU1LDY0MCAgSU5GTyBEcml2ZXJNYW5hZ2VyQ29ubmVjdGlvblByb3ZpZGVyOjQyIC0gSGliZXJu
YXRlIGNvbm5lY3Rpb24gcG9vbCBzaXplOiAxDQoxMzoyNjo1NSw2NDAgIElORk8gRHJpdmVyTWFu
YWdlckNvbm5lY3Rpb25Qcm92aWRlcjo0NSAtIGF1dG9jb21taXQgbW9kZTogZmFsc2UNCjEzOjI2
OjU1LDY0MCAgSU5GTyBEcml2ZXJNYW5hZ2VyQ29ubmVjdGlvblByb3ZpZGVyOjgwIC0gdXNpbmcg
ZHJpdmVyOiBvcmcucG9zdGdyZXNxbC5Ecml2ZXIgYXQgVVJMOiBqZGJjOnBvc3RncmVzcWw6Ly9s
b2NhbGhvc3Q6NTQzMi9ndmRiDQoxMzoyNjo1NSw2NDAgIElORk8gRHJpdmVyTWFuYWdlckNvbm5l
Y3Rpb25Qcm92aWRlcjo4NiAtIGNvbm5lY3Rpb24gcHJvcGVydGllczoge3VzZXI9cG9zdGdyZXMs
IHBhc3N3b3JkPSoqKip9DQoxMzoyNjo1NSw3MDMgIElORk8gU2V0dGluZ3NGYWN0b3J5Ojc3IC0g
UkRCTVM6IFBvc3RncmVTUUwsIHZlcnNpb246IDguMS40DQoxMzoyNjo1NSw3MDMgIElORk8gU2V0
dGluZ3NGYWN0b3J5Ojc4IC0gSkRCQyBkcml2ZXI6IFBvc3RncmVTUUwgTmF0aXZlIERyaXZlciwg
dmVyc2lvbjogUG9zdGdyZVNRTCA4LjAgSkRCQzMgd2l0aCBTU0wgKGJ1aWxkIDMxMSkNCjEzOjI2
OjU1LDcwMyAgSU5GTyBEaWFsZWN0OjEwMCAtIFVzaW5nIGRpYWxlY3Q6IG9yZy5oaWJlcm5hdGUu
ZGlhbGVjdC5Qb3N0Z3JlU1FMRGlhbGVjdA0KMTM6MjY6NTUsNzAzICBJTkZPIFRyYW5zYWN0aW9u
RmFjdG9yeUZhY3Rvcnk6MzEgLSBVc2luZyBkZWZhdWx0IHRyYW5zYWN0aW9uIHN0cmF0ZWd5IChk
aXJlY3QgSkRCQyB0cmFuc2FjdGlvbnMpDQoxMzoyNjo1NSw3MDMgIElORk8gVHJhbnNhY3Rpb25N
YW5hZ2VyTG9va3VwRmFjdG9yeTozMyAtIE5vIFRyYW5zYWN0aW9uTWFuYWdlckxvb2t1cCBjb25m
aWd1cmVkIChpbiBKVEEgZW52aXJvbm1lbnQsIHVzZSBvZiByZWFkLXdyaXRlIG9yIHRyYW5zYWN0
aW9uYWwgc2Vjb25kLWxldmVsIGNhY2hlIGlzIG5vdCByZWNvbW1lbmRlZCkNCjEzOjI2OjU1LDcw
MyAgSU5GTyBTZXR0aW5nc0ZhY3Rvcnk6MTI1IC0gQXV0b21hdGljIGZsdXNoIGR1cmluZyBiZWZv
cmVDb21wbGV0aW9uKCk6IGRpc2FibGVkDQoxMzoyNjo1NSw3MDMgIElORk8gU2V0dGluZ3NGYWN0
b3J5OjEyOSAtIEF1dG9tYXRpYyBzZXNzaW9uIGNsb3NlIGF0IGVuZCBvZiB0cmFuc2FjdGlvbjog
ZGlzYWJsZWQNCjEzOjI2OjU1LDcxOCAgSU5GTyBTZXR0aW5nc0ZhY3Rvcnk6MTM2IC0gSkRCQyBi
YXRjaCBzaXplOiAxNQ0KMTM6MjY6NTUsNzE4ICBJTkZPIFNldHRpbmdzRmFjdG9yeToxMzkgLSBK
REJDIGJhdGNoIHVwZGF0ZXMgZm9yIHZlcnNpb25lZCBkYXRhOiBlbmFibGVkDQoxMzoyNjo1NSw3
MTggIElORk8gU2V0dGluZ3NGYWN0b3J5OjE0NCAtIFNjcm9sbGFibGUgcmVzdWx0IHNldHM6IGVu
YWJsZWQNCjEzOjI2OjU1LDcxOCAgSU5GTyBTZXR0aW5nc0ZhY3Rvcnk6MTUyIC0gSkRCQzMgZ2V0
R2VuZXJhdGVkS2V5cygpOiBkaXNhYmxlZA0KMTM6MjY6NTUsNzE4ICBJTkZPIFNldHRpbmdzRmFj
dG9yeToxNjAgLSBDb25uZWN0aW9uIHJlbGVhc2UgbW9kZTogbnVsbA0KMTM6MjY6NTUsNzE4ICBJ
TkZPIFNldHRpbmdzRmFjdG9yeToxODQgLSBNYXhpbXVtIG91dGVyIGpvaW4gZmV0Y2ggZGVwdGg6
IDENCjEzOjI2OjU1LDcxOCAgSU5GTyBTZXR0aW5nc0ZhY3Rvcnk6MTg3IC0gRGVmYXVsdCBiYXRj
aCBmZXRjaCBzaXplOiAxDQoxMzoyNjo1NSw3MTggIElORk8gU2V0dGluZ3NGYWN0b3J5OjE5MSAt
IEdlbmVyYXRlIFNRTCB3aXRoIGNvbW1lbnRzOiBkaXNhYmxlZA0KMTM6MjY6NTUsNzE4ICBJTkZP
IFNldHRpbmdzRmFjdG9yeToxOTUgLSBPcmRlciBTUUwgdXBkYXRlcyBieSBwcmltYXJ5IGtleTog
ZGlzYWJsZWQNCjEzOjI2OjU1LDcxOCAgSU5GTyBTZXR0aW5nc0ZhY3Rvcnk6MzM4IC0gUXVlcnkg
dHJhbnNsYXRvcjogb3JnLmhpYmVybmF0ZS5ocWwuYXN0LkFTVFF1ZXJ5VHJhbnNsYXRvckZhY3Rv
cnkNCjEzOjI2OjU1LDcxOCAgSU5GTyBBU1RRdWVyeVRyYW5zbGF0b3JGYWN0b3J5OjIxIC0gVXNp
bmcgQVNUUXVlcnlUcmFuc2xhdG9yRmFjdG9yeQ0KMTM6MjY6NTUsNzE4ICBJTkZPIFNldHRpbmdz
RmFjdG9yeToyMDMgLSBRdWVyeSBsYW5ndWFnZSBzdWJzdGl0dXRpb25zOiB7eWVzPSdZJywgbm89
J04nfQ0KMTM6MjY6NTUsNzE4ICBJTkZPIFNldHRpbmdzRmFjdG9yeToyMDkgLSBTZWNvbmQtbGV2
ZWwgY2FjaGU6IGVuYWJsZWQNCjEzOjI2OjU1LDcxOCAgSU5GTyBTZXR0aW5nc0ZhY3Rvcnk6MjEz
IC0gUXVlcnkgY2FjaGU6IGRpc2FibGVkDQoxMzoyNjo1NSw3MTggIElORk8gU2V0dGluZ3NGYWN0
b3J5OjMyNSAtIENhY2hlIHByb3ZpZGVyOiBvcmcuaGliZXJuYXRlLmNhY2hlLkhhc2h0YWJsZUNh
Y2hlUHJvdmlkZXINCjEzOjI2OjU1LDcxOCAgSU5GTyBTZXR0aW5nc0ZhY3Rvcnk6MjI4IC0gT3B0
aW1pemUgY2FjaGUgZm9yIG1pbmltYWwgcHV0czogZGlzYWJsZWQNCjEzOjI2OjU1LDcxOCAgSU5G
TyBTZXR0aW5nc0ZhY3Rvcnk6MjMzIC0gQ2FjaGUgcmVnaW9uIHByZWZpeDogaGliZXJuYXRlLnRl
c3QNCjEzOjI2OjU1LDcxOCAgSU5GTyBTZXR0aW5nc0ZhY3Rvcnk6MjM3IC0gU3RydWN0dXJlZCBz
ZWNvbmQtbGV2ZWwgY2FjaGUgZW50cmllczogZGlzYWJsZWQNCjEzOjI2OjU1LDcxOCAgSU5GTyBT
ZXR0aW5nc0ZhY3Rvcnk6MjU3IC0gRWNob2luZyBhbGwgU1FMIHRvIHN0ZG91dA0KMTM6MjY6NTUs
NzE4ICBJTkZPIFNldHRpbmdzRmFjdG9yeToyNjQgLSBTdGF0aXN0aWNzOiBkaXNhYmxlZA0KMTM6
MjY6NTUsNzE4ICBJTkZPIFNldHRpbmdzRmFjdG9yeToyNjggLSBEZWxldGVkIGVudGl0eSBzeW50
aGV0aWMgaWRlbnRpZmllciByb2xsYmFjazogZGlzYWJsZWQNCjEzOjI2OjU1LDcxOCAgSU5GTyBT
ZXR0aW5nc0ZhY3Rvcnk6MjgzIC0gRGVmYXVsdCBlbnRpdHktbW9kZTogUE9KTw0KMTM6MjY6NTUs
NzE4ICBJTkZPIFNlc3Npb25GYWN0b3J5SW1wbDoxNTcgLSBidWlsZGluZyBzZXNzaW9uIGZhY3Rv
cnkNCjEzOjI2OjU2LDU2MiAgSU5GTyBEcml2ZXJNYW5hZ2VyQ29ubmVjdGlvblByb3ZpZGVyOjE0
NyAtIGNsZWFuaW5nIHVwIGNvbm5lY3Rpb24gcG9vbDogamRiYzpwb3N0Z3Jlc3FsOi8vbG9jYWxo
b3N0OjU0MzIvZ3ZkYg0KMTM6MjY6NTYsNTYyICBJTkZPIERyaXZlck1hbmFnZXJDb25uZWN0aW9u
UHJvdmlkZXI6MTQ3IC0gY2xlYW5pbmcgdXAgY29ubmVjdGlvbiBwb29sOiBqZGJjOnBvc3RncmVz
cWw6Ly9sb2NhbGhvc3Q6NTQzMi9ndmRiDQoxMzoyNjo1OSw0MDYgRVJST1IgQmFzaWNMYXp5SW5p
dGlhbGl6ZXI6MTA1IC0gQ0dMSUIgRW5oYW5jZW1lbnQgZmFpbGVkOiBjb20uaW5zZXF1ZW5jZS5n
di5Qcm9kdWN0T3JkZXINCm5ldC5zZi5jZ2xpYi5jb3JlLkNvZGVHZW5lcmF0aW9uRXhjZXB0aW9u
OiBqYXZhLmxhbmcucmVmbGVjdC5JbnZvY2F0aW9uVGFyZ2V0RXhjZXB0aW9uLS0+bnVsbA0KCWF0
IG5ldC5zZi5jZ2xpYi5jb3JlLkFic3RyYWN0Q2xhc3NHZW5lcmF0b3IuY3JlYXRlKEFic3RyYWN0
Q2xhc3NHZW5lcmF0b3IuamF2YToyMzYpDQoJYXQgbmV0LnNmLmNnbGliLnByb3h5LkVuaGFuY2Vy
LmNyZWF0ZUhlbHBlcihFbmhhbmNlci5qYXZhOjM3NykNCglhdCBuZXQuc2YuY2dsaWIucHJveHku
RW5oYW5jZXIuY3JlYXRlQ2xhc3MoRW5oYW5jZXIuamF2YTozMTcpDQoJYXQgb3JnLmhpYmVybmF0
ZS5wcm94eS5DR0xJQkxhenlJbml0aWFsaXplci5nZXRQcm94eUZhY3RvcnkoQ0dMSUJMYXp5SW5p
dGlhbGl6ZXIuamF2YToxMDEpDQoJYXQgb3JnLmhpYmVybmF0ZS5wcm94eS5DR0xJQlByb3h5RmFj
dG9yeS5wb3N0SW5zdGFudGlhdGUoQ0dMSUJQcm94eUZhY3RvcnkuamF2YTo0MSkNCglhdCBvcmcu
aGliZXJuYXRlLnR1cGxlLlBvam9FbnRpdHlUdXBsaXplci5idWlsZFByb3h5RmFjdG9yeShQb2pv
RW50aXR5VHVwbGl6ZXIuamF2YToxNjEpDQoJYXQgb3JnLmhpYmVybmF0ZS50dXBsZS5BYnN0cmFj
dEVudGl0eVR1cGxpemVyLjxpbml0PihBYnN0cmFjdEVudGl0eVR1cGxpemVyLmphdmE6MTMxKQ0K
CWF0IG9yZy5oaWJlcm5hdGUudHVwbGUuUG9qb0VudGl0eVR1cGxpemVyLjxpbml0PihQb2pvRW50
aXR5VHVwbGl6ZXIuamF2YTo1NSkNCglhdCBvcmcuaGliZXJuYXRlLnR1cGxlLlR1cGxpemVyTG9v
a3VwLmNyZWF0ZShUdXBsaXplckxvb2t1cC5qYXZhOjY0KQ0KCWF0IG9yZy5oaWJlcm5hdGUudHVw
bGUuRW50aXR5TWV0YW1vZGVsLjxpbml0PihFbnRpdHlNZXRhbW9kZWwuamF2YToyNDYpDQoJYXQg
b3JnLmhpYmVybmF0ZS5wZXJzaXN0ZXIuZW50aXR5LkFic3RyYWN0RW50aXR5UGVyc2lzdGVyLjxp
bml0PihBYnN0cmFjdEVudGl0eVBlcnNpc3Rlci5qYXZhOjQxMCkNCglhdCBvcmcuaGliZXJuYXRl
LnBlcnNpc3Rlci5lbnRpdHkuU2luZ2xlVGFibGVFbnRpdHlQZXJzaXN0ZXIuPGluaXQ+KFNpbmds
ZVRhYmxlRW50aXR5UGVyc2lzdGVyLmphdmE6MTA4KQ0KCWF0IG9yZy5oaWJlcm5hdGUucGVyc2lz
dGVyLlBlcnNpc3RlckZhY3RvcnkuY3JlYXRlQ2xhc3NQZXJzaXN0ZXIoUGVyc2lzdGVyRmFjdG9y
eS5qYXZhOjU1KQ0KCWF0IG9yZy5oaWJlcm5hdGUuaW1wbC5TZXNzaW9uRmFjdG9yeUltcGwuPGlu
aXQ+KFNlc3Npb25GYWN0b3J5SW1wbC5qYXZhOjIxOSkNCglhdCBvcmcuaGliZXJuYXRlLmNmZy5D
b25maWd1cmF0aW9uLmJ1aWxkU2Vzc2lvbkZhY3RvcnkoQ29uZmlndXJhdGlvbi5qYXZhOjExMjcp
DQoJYXQgY29tLmluc2VxdWVuY2UuZ3YuTG9naW5TZXJ2bGV0LnRlc3RMb2dpbihMb2dpblNlcnZs
ZXQuamF2YToxMTQpDQoJYXQgY29tLmluc2VxdWVuY2UuZ3YuTG9naW5TZXJ2bGV0LmRvUG9zdChM
b2dpblNlcnZsZXQuamF2YTo0MSkNCglhdCBqYXZheC5zZXJ2bGV0Lmh0dHAuSHR0cFNlcnZsZXQu
c2VydmljZShIdHRwU2VydmxldC5qYXZhOjcxMCkNCglhdCBqYXZheC5zZXJ2bGV0Lmh0dHAuSHR0
cFNlcnZsZXQuc2VydmljZShIdHRwU2VydmxldC5qYXZhOjgwMykNCglhdCBvcmcuYXBhY2hlLmNh
dGFsaW5hLmNvcmUuQXBwbGljYXRpb25GaWx0ZXJDaGFpbi5pbnRlcm5hbERvRmlsdGVyKEFwcGxp
Y2F0aW9uRmlsdGVyQ2hhaW4uamF2YToyNjkpDQoJYXQgb3JnLmFwYWNoZS5jYXRhbGluYS5jb3Jl
LkFwcGxpY2F0aW9uRmlsdGVyQ2hhaW4uZG9GaWx0ZXIoQXBwbGljYXRpb25GaWx0ZXJDaGFpbi5q
YXZhOjE4OCkNCglhdCBvcmcuYXBhY2hlLmNhdGFsaW5hLmNvcmUuU3RhbmRhcmRXcmFwcGVyVmFs
dmUuaW52b2tlKFN0YW5kYXJkV3JhcHBlclZhbHZlLmphdmE6MjEwKQ0KCWF0IG9yZy5hcGFjaGUu
Y2F0YWxpbmEuY29yZS5TdGFuZGFyZENvbnRleHRWYWx2ZS5pbnZva2UoU3RhbmRhcmRDb250ZXh0
VmFsdmUuamF2YToxNzQpDQoJYXQgb3JnLmFwYWNoZS5jYXRhbGluYS5jb3JlLlN0YW5kYXJkSG9z
dFZhbHZlLmludm9rZShTdGFuZGFyZEhvc3RWYWx2ZS5qYXZhOjEyNykNCglhdCBvcmcuYXBhY2hl
LmNhdGFsaW5hLnZhbHZlcy5FcnJvclJlcG9ydFZhbHZlLmludm9rZShFcnJvclJlcG9ydFZhbHZl
LmphdmE6MTE3KQ0KCWF0IG9yZy5hcGFjaGUuY2F0YWxpbmEuY29yZS5TdGFuZGFyZEVuZ2luZVZh
bHZlLmludm9rZShTdGFuZGFyZEVuZ2luZVZhbHZlLmphdmE6MTA4KQ0KCWF0IG9yZy5hcGFjaGUu
Y2F0YWxpbmEuY29ubmVjdG9yLkNveW90ZUFkYXB0ZXIuc2VydmljZShDb3lvdGVBZGFwdGVyLmph
dmE6MTUxKQ0KCWF0IG9yZy5hcGFjaGUuY295b3RlLmh0dHAxMS5IdHRwMTFQcm9jZXNzb3IucHJv
Y2VzcyhIdHRwMTFQcm9jZXNzb3IuamF2YTo4NzApDQoJYXQgb3JnLmFwYWNoZS5jb3lvdGUuaHR0
cDExLkh0dHAxMUJhc2VQcm90b2NvbCRIdHRwMTFDb25uZWN0aW9uSGFuZGxlci5wcm9jZXNzQ29u
bmVjdGlvbihIdHRwMTFCYXNlUHJvdG9jb2wuamF2YTo2NjUpDQoJYXQgb3JnLmFwYWNoZS50b21j
YXQudXRpbC5uZXQuUG9vbFRjcEVuZHBvaW50LnByb2Nlc3NTb2NrZXQoUG9vbFRjcEVuZHBvaW50
LmphdmE6NTI4KQ0KCWF0IG9yZy5hcGFjaGUudG9tY2F0LnV0aWwubmV0LkxlYWRlckZvbGxvd2Vy
V29ya2VyVGhyZWFkLnJ1bkl0KExlYWRlckZvbGxvd2VyV29ya2VyVGhyZWFkLmphdmE6ODEpDQoJ
YXQgb3JnLmFwYWNoZS50b21jYXQudXRpbC50aHJlYWRzLlRocmVhZFBvb2wkQ29udHJvbFJ1bm5h
YmxlLnJ1bihUaHJlYWRQb29sLmphdmE6Njg1KQ0KCWF0IGphdmEubGFuZy5UaHJlYWQucnVuKFRo
cmVhZC5qYXZhOjYxOSkNCkNhdXNlZCBieTogamF2YS5sYW5nLnJlZmxlY3QuSW52b2NhdGlvblRh
cmdldEV4Y2VwdGlvbg0KCWF0IHN1bi5yZWZsZWN0LkdlbmVyYXRlZE1ldGhvZEFjY2Vzc29yMTE2
Lmludm9rZShVbmtub3duIFNvdXJjZSkNCglhdCBzdW4ucmVmbGVjdC5EZWxlZ2F0aW5nTWV0aG9k
QWNjZXNzb3JJbXBsLmludm9rZShEZWxlZ2F0aW5nTWV0aG9kQWNjZXNzb3JJbXBsLmphdmE6MjUp
DQoJYXQgamF2YS5sYW5nLnJlZmxlY3QuTWV0aG9kLmludm9rZShNZXRob2QuamF2YTo1OTcpDQoJ
YXQgbmV0LnNmLmNnbGliLmNvcmUuUmVmbGVjdFV0aWxzLmRlZmluZUNsYXNzKFJlZmxlY3RVdGls
cy5qYXZhOjM4NCkNCglhdCBuZXQuc2YuY2dsaWIuY29yZS5BYnN0cmFjdENsYXNzR2VuZXJhdG9y
LmNyZWF0ZShBYnN0cmFjdENsYXNzR2VuZXJhdG9yLmphdmE6MjE4KQ0KCS4uLiAzMiBtb3JlDQpD
YXVzZWQgYnk6IGphdmEubGFuZy5PdXRPZk1lbW9yeUVycm9yOiBQZXJtR2VuIHNwYWNlDQoJYXQg
amF2YS5sYW5nLkNsYXNzTG9hZGVyLmRlZmluZUNsYXNzMShOYXRpdmUgTWV0aG9kKQ0KCWF0IGph
dmEubGFuZy5DbGFzc0xvYWRlci5kZWZpbmVDbGFzcyhDbGFzc0xvYWRlci5qYXZhOjYyMCkNCglh
dCBzdW4ucmVmbGVjdC5HZW5lcmF0ZWRNZXRob2RBY2Nlc3NvcjExNi5pbnZva2UoVW5rbm93biBT
b3VyY2UpDQoJYXQgc3VuLnJlZmxlY3QuRGVsZWdhdGluZ01ldGhvZEFjY2Vzc29ySW1wbC5pbnZv
a2UoRGVsZWdhdGluZ01ldGhvZEFjY2Vzc29ySW1wbC5qYXZhOjI1KQ0KCWF0IGphdmEubGFuZy5y
ZWZsZWN0Lk1ldGhvZC5pbnZva2UoTWV0aG9kLmphdmE6NTk3KQ0KCWF0IG5ldC5zZi5jZ2xpYi5j
b3JlLlJlZmxlY3RVdGlscy5kZWZpbmVDbGFzcyhSZWZsZWN0VXRpbHMuamF2YTozODQpDQoJYXQg
bmV0LnNmLmNnbGliLmNvcmUuQWJzdHJhY3RDbGFzc0dlbmVyYXRvci5jcmVhdGUoQWJzdHJhY3RD
bGFzc0dlbmVyYXRvci5qYXZhOjIxOCkNCglhdCBuZXQuc2YuY2dsaWIucHJveHkuRW5oYW5jZXIu
Y3JlYXRlSGVscGVyKEVuaGFuY2VyLmphdmE6Mzc3KQ0KCWF0IG5ldC5zZi5jZ2xpYi5wcm94eS5F
bmhhbmNlci5jcmVhdGVDbGFzcyhFbmhhbmNlci5qYXZhOjMxNykNCglhdCBvcmcuaGliZXJuYXRl
LnByb3h5LkNHTElCTGF6eUluaXRpYWxpemVyLmdldFByb3h5RmFjdG9yeShDR0xJQkxhenlJbml0
aWFsaXplci5qYXZhOjEwMSkNCglhdCBvcmcuaGliZXJuYXRlLnByb3h5LkNHTElCUHJveHlGYWN0
b3J5LnBvc3RJbnN0YW50aWF0ZShDR0xJQlByb3h5RmFjdG9yeS5qYXZhOjQxKQ0KCWF0IG9yZy5o
aWJlcm5hdGUudHVwbGUuUG9qb0VudGl0eVR1cGxpemVyLmJ1aWxkUHJveHlGYWN0b3J5KFBvam9F
bnRpdHlUdXBsaXplci5qYXZhOjE2MSkNCglhdCBvcmcuaGliZXJuYXRlLnR1cGxlLkFic3RyYWN0
RW50aXR5VHVwbGl6ZXIuPGluaXQ+KEFic3RyYWN0RW50aXR5VHVwbGl6ZXIuamF2YToxMzEpDQoJ
YXQgb3JnLmhpYmVybmF0ZS50dXBsZS5Qb2pvRW50aXR5VHVwbGl6ZXIuPGluaXQ+KFBvam9FbnRp
dHlUdXBsaXplci5qYXZhOjU1KQ0KCWF0IG9yZy5oaWJlcm5hdGUudHVwbGUuVHVwbGl6ZXJMb29r
dXAuY3JlYXRlKFR1cGxpemVyTG9va3VwLmphdmE6NjQpDQoJYXQgb3JnLmhpYmVybmF0ZS50dXBs
ZS5FbnRpdHlNZXRhbW9kZWwuPGluaXQ+KEVudGl0eU1ldGFtb2RlbC5qYXZhOjI0NikNCglhdCBv
cmcuaGliZXJuYXRlLnBlcnNpc3Rlci5lbnRpdHkuQWJzdHJhY3RFbnRpdHlQZXJzaXN0ZXIuPGlu
aXQ+KEFic3RyYWN0RW50aXR5UGVyc2lzdGVyLmphdmE6NDEwKQ0KCWF0IG9yZy5oaWJlcm5hdGUu
cGVyc2lzdGVyLmVudGl0eS5TaW5nbGVUYWJsZUVudGl0eVBlcnNpc3Rlci48aW5pdD4oU2luZ2xl
VGFibGVFbnRpdHlQZXJzaXN0ZXIuamF2YToxMDgpDQoJYXQgb3JnLmhpYmVybmF0ZS5wZXJzaXN0
ZXIuUGVyc2lzdGVyRmFjdG9yeS5jcmVhdGVDbGFzc1BlcnNpc3RlcihQZXJzaXN0ZXJGYWN0b3J5
LmphdmE6NTUpDQoJYXQgb3JnLmhpYmVybmF0ZS5pbXBsLlNlc3Npb25GYWN0b3J5SW1wbC48aW5p
dD4oU2Vzc2lvbkZhY3RvcnlJbXBsLmphdmE6MjE5KQ0KCWF0IG9yZy5oaWJlcm5hdGUuY2ZnLkNv
bmZpZ3VyYXRpb24uYnVpbGRTZXNzaW9uRmFjdG9yeShDb25maWd1cmF0aW9uLmphdmE6MTEyNykN
CglhdCBjb20uaW5zZXF1ZW5jZS5ndi5Mb2dpblNlcnZsZXQudGVzdExvZ2luKExvZ2luU2Vydmxl
dC5qYXZhOjExNCkNCglhdCBjb20uaW5zZXF1ZW5jZS5ndi5Mb2dpblNlcnZsZXQuZG9Qb3N0KExv
Z2luU2VydmxldC5qYXZhOjQxKQ0KCWF0IGphdmF4LnNlcnZsZXQuaHR0cC5IdHRwU2VydmxldC5z
ZXJ2aWNlKEh0dHBTZXJ2bGV0LmphdmE6NzEwKQ0KCWF0IGphdmF4LnNlcnZsZXQuaHR0cC5IdHRw
U2VydmxldC5zZXJ2aWNlKEh0dHBTZXJ2bGV0LmphdmE6ODAzKQ0KCWF0IG9yZy5hcGFjaGUuY2F0
YWxpbmEuY29yZS5BcHBsaWNhdGlvbkZpbHRlckNoYWluLmludGVybmFsRG9GaWx0ZXIoQXBwbGlj
YXRpb25GaWx0ZXJDaGFpbi5qYXZhOjI2OSkNCglhdCBvcmcuYXBhY2hlLmNhdGFsaW5hLmNvcmUu
QXBwbGljYXRpb25GaWx0ZXJDaGFpbi5kb0ZpbHRlcihBcHBsaWNhdGlvbkZpbHRlckNoYWluLmph
dmE6MTg4KQ0KCWF0IG9yZy5hcGFjaGUuY2F0YWxpbmEuY29yZS5TdGFuZGFyZFdyYXBwZXJWYWx2
ZS5pbnZva2UoU3RhbmRhcmRXcmFwcGVyVmFsdmUuamF2YToyMTApDQoJYXQgb3JnLmFwYWNoZS5j
YXRhbGluYS5jb3JlLlN0YW5kYXJkQ29udGV4dFZhbHZlLmludm9rZShTdGFuZGFyZENvbnRleHRW
YWx2ZS5qYXZhOjE3NCkNCglhdCBvcmcuYXBhY2hlLmNhdGFsaW5hLmNvcmUuU3RhbmRhcmRIb3N0
VmFsdmUuaW52b2tlKFN0YW5kYXJkSG9zdFZhbHZlLmphdmE6MTI3KQ0KCWF0IG9yZy5hcGFjaGUu
Y2F0YWxpbmEudmFsdmVzLkVycm9yUmVwb3J0VmFsdmUuaW52b2tlKEVycm9yUmVwb3J0VmFsdmUu
amF2YToxMTcpDQoJYXQgb3JnLmFwYWNoZS5jYXRhbGluYS5jb3JlLlN0YW5kYXJkRW5naW5lVmFs
dmUuaW52b2tlKFN0YW5kYXJkRW5naW5lVmFsdmUuamF2YToxMDgpDQoxMzoyNzowMSw4NzUgRVJS
T1IgW0xvZ2luU2VydmxldF06MjU3IC0gU2VydmxldC5zZXJ2aWNlKCkgZm9yIHNlcnZsZXQgTG9n
aW5TZXJ2bGV0IHRocmV3IGV4Y2VwdGlvbg0KamF2YS5sYW5nLk51bGxQb2ludGVyRXhjZXB0aW9u
DQoJYXQgY29tLmluc2VxdWVuY2UuZ3YuTG9naW5TZXJ2bGV0LnRlc3RMb2dpbihMb2dpblNlcnZs
ZXQuamF2YToxMzcpDQoJYXQgY29tLmluc2VxdWVuY2UuZ3YuTG9naW5TZXJ2bGV0LmRvUG9zdChM
b2dpblNlcnZsZXQuamF2YTo0MSkNCglhdCBqYXZheC5zZXJ2bGV0Lmh0dHAuSHR0cFNlcnZsZXQu
c2VydmljZShIdHRwU2VydmxldC5qYXZhOjcxMCkNCglhdCBqYXZheC5zZXJ2bGV0Lmh0dHAuSHR0
cFNlcnZsZXQuc2VydmljZShIdHRwU2VydmxldC5qYXZhOjgwMykNCglhdCBvcmcuYXBhY2hlLmNh
dGFsaW5hLmNvcmUuQXBwbGljYXRpb25GaWx0ZXJDaGFpbi5pbnRlcm5hbERvRmlsdGVyKEFwcGxp
Y2F0aW9uRmlsdGVyQ2hhaW4uamF2YToyNjkpDQoJYXQgb3JnLmFwYWNoZS5jYXRhbGluYS5jb3Jl
LkFwcGxpY2F0aW9uRmlsdGVyQ2hhaW4uZG9GaWx0ZXIoQXBwbGljYXRpb25GaWx0ZXJDaGFpbi5q
YXZhOjE4OCkNCglhdCBvcmcuYXBhY2hlLmNhdGFsaW5hLmNvcmUuU3RhbmRhcmRXcmFwcGVyVmFs
dmUuaW52b2tlKFN0YW5kYXJkV3JhcHBlclZhbHZlLmphdmE6MjEwKQ0KCWF0IG9yZy5hcGFjaGUu
Y2F0YWxpbmEuY29yZS5TdGFuZGFyZENvbnRleHRWYWx2ZS5pbnZva2UoU3RhbmRhcmRDb250ZXh0
VmFsdmUuamF2YToxNzQpDQoJYXQgb3JnLmFwYWNoZS5jYXRhbGluYS5jb3JlLlN0YW5kYXJkSG9z
dFZhbHZlLmludm9rZShTdGFuZGFyZEhvc3RWYWx2ZS5qYXZhOjEyNykNCglhdCBvcmcuYXBhY2hl
LmNhdGFsaW5hLnZhbHZlcy5FcnJvclJlcG9ydFZhbHZlLmludm9rZShFcnJvclJlcG9ydFZhbHZl
LmphdmE6MTE3KQ0KCWF0IG9yZy5hcGFjaGUuY2F0YWxpbmEuY29yZS5TdGFuZGFyZEVuZ2luZVZh
bHZlLmludm9rZShTdGFuZGFyZEVuZ2luZVZhbHZlLmphdmE6MTA4KQ0KCWF0IG9yZy5hcGFjaGUu
Y2F0YWxpbmEuY29ubmVjdG9yLkNveW90ZUFkYXB0ZXIuc2VydmljZShDb3lvdGVBZGFwdGVyLmph
dmE6MTUxKQ0KCWF0IG9yZy5hcGFjaGUuY295b3RlLmh0dHAxMS5IdHRwMTFQcm9jZXNzb3IucHJv
Y2VzcyhIdHRwMTFQcm9jZXNzb3IuamF2YTo4NzApDQoJYXQgb3JnLmFwYWNoZS5jb3lvdGUuaHR0
cDExLkh0dHAxMUJhc2VQcm90b2NvbCRIdHRwMTFDb25uZWN0aW9uSGFuZGxlci5wcm9jZXNzQ29u
bmVjdGlvbihIdHRwMTFCYXNlUHJvdG9jb2wuamF2YTo2NjUpDQoJYXQgb3JnLmFwYWNoZS50b21j
YXQudXRpbC5uZXQuUG9vbFRjcEVuZHBvaW50LnByb2Nlc3NTb2NrZXQoUG9vbFRjcEVuZHBvaW50
LmphdmE6NTI4KQ0KCWF0IG9yZy5hcGFjaGUudG9tY2F0LnV0aWwubmV0LkxlYWRlckZvbGxvd2Vy
V29ya2VyVGhyZWFkLnJ1bkl0KExlYWRlckZvbGxvd2VyV29ya2VyVGhyZWFkLmphdmE6ODEpDQoJ
YXQgb3JnLmFwYWNoZS50b21jYXQudXRpbC50aHJlYWRzLlRocmVhZFBvb2wkQ29udHJvbFJ1bm5h
YmxlLnJ1bihUaHJlYWRQb29sLmphdmE6Njg1KQ0KCWF0IGphdmEubGFuZy5UaHJlYWQucnVuKFRo
cmVhZC5qYXZhOjYxOSkNCjEzOjI3OjAxLDg3NSAgSU5GTyBEcml2ZXJNYW5hZ2VyQ29ubmVjdGlv
blByb3ZpZGVyOjE0NyAtIGNsZWFuaW5nIHVwIGNvbm5lY3Rpb24gcG9vbDogamRiYzpwb3N0Z3Jl
c3FsOi8vbG9jYWxob3N0OjU0MzIvZ3ZkYg0KMTM6Mjc6MjEsOTUzICBJTkZPIENvbmZpZ3VyYXRp
b246MTIzOSAtIGNvbmZpZ3VyaW5nIGZyb20gcmVzb3VyY2U6IC9oaWJlcm5hdGUuY2ZnLnhtbA0K
MTM6Mjc6MjEsOTUzICBJTkZPIENvbmZpZ3VyYXRpb246MTIxNiAtIENvbmZpZ3VyYXRpb24gcmVz
b3VyY2U6IC9oaWJlcm5hdGUuY2ZnLnhtbA0KMTM6Mjc6MjEsOTY4ICBJTkZPIENvbmZpZ3VyYXRp
b246NDYwIC0gUmVhZGluZyBtYXBwaW5ncyBmcm9tIHJlc291cmNlOiBTdXBwbGllcjEuaGJtLnht
bA0KMTM6Mjc6MjEsOTY4ICBJTkZPIEhibUJpbmRlcjozMTEgLSBNYXBwaW5nIGNsYXNzOiBjb20u
aW5zZXF1ZW5jZS5ndi5TdXBwbGllcjEgLT4gc3VwcGxpZXIxDQoxMzoyNzoyMSw5NjggIElORk8g
Q29uZmlndXJhdGlvbjo0NjAgLSBSZWFkaW5nIG1hcHBpbmdzIGZyb20gcmVzb3VyY2U6IFN1cHBs
aWVyMi5oYm0ueG1sDQoxMzoyNzoyMSw5NjggIElORk8gSGJtQmluZGVyOjMxMSAtIE1hcHBpbmcg
Y2xhc3M6IGNvbS5pbnNlcXVlbmNlLmd2LlN1cHBsaWVyMiAtPiBzdXBwbGllcjINCjEzOjI3OjIx
LDk2OCAgSU5GTyBDb25maWd1cmF0aW9uOjQ2MCAtIFJlYWRpbmcgbWFwcGluZ3MgZnJvbSByZXNv
dXJjZTogU3VwcGxpZXIzLmhibS54bWwNCjEzOjI3OjIxLDk4NCAgSU5GTyBIYm1CaW5kZXI6MzEx
IC0gTWFwcGluZyBjbGFzczogY29tLmluc2VxdWVuY2UuZ3YuU3VwcGxpZXIzIC0+IHN1cHBsaWVy
Mw0KMTM6Mjc6MjEsOTg0ICBJTkZPIENvbmZpZ3VyYXRpb246NDYwIC0gUmVhZGluZyBtYXBwaW5n
cyBmcm9tIHJlc291cmNlOiBTdXBwbGllckVhcnRoRGF0YS5oYm0ueG1sDQoxMzoyNzoyMSw5ODQg
IElORk8gSGJtQmluZGVyOjMxMSAtIE1hcHBpbmcgY2xhc3M6IGNvbS5pbnNlcXVlbmNlLmd2LlN1
cHBsaWVyRWFydGhEYXRhIC0+IHN1cHBsaWVyX2VhcnRoZGF0YQ0KMTM6Mjc6MjEsOTg0ICBJTkZP
IENvbmZpZ3VyYXRpb246NDYwIC0gUmVhZGluZyBtYXBwaW5ncyBmcm9tIHJlc291cmNlOiBTdXBw
bGllcjMwMDEuaGJtLnhtbA0KMTM6Mjc6MjIsMDAwICBJTkZPIEhibUJpbmRlcjozMTEgLSBNYXBw
aW5nIGNsYXNzOiBjb20uaW5zZXF1ZW5jZS5ndi5TdXBwbGllcjMwMDEgLT4gc3VwcGxpZXJfMzAw
MQ0KMTM6Mjc6MjIsMDAwICBJTkZPIENvbmZpZ3VyYXRpb246NDYwIC0gUmVhZGluZyBtYXBwaW5n
cyBmcm9tIHJlc291cmNlOiBTdXBwbGllck5HQS5oYm0ueG1sDQoxMzoyNzoyMiwwMDAgIElORk8g
SGJtQmluZGVyOjMxMSAtIE1hcHBpbmcgY2xhc3M6IGNvbS5pbnNlcXVlbmNlLmd2LlN1cHBsaWVy
TkdBIC0+IHN1cHBsaWVyX25nYQ0KMTM6Mjc6MjIsMDAwICBJTkZPIENvbmZpZ3VyYXRpb246NDYw
IC0gUmVhZGluZyBtYXBwaW5ncyBmcm9tIHJlc291cmNlOiBTdXBwbGllck5HQUdyaWQuaGJtLnht
bA0KMTM6Mjc6MjIsMDAwICBJTkZPIEhibUJpbmRlcjozMTEgLSBNYXBwaW5nIGNsYXNzOiBjb20u
aW5zZXF1ZW5jZS5ndi5TdXBwbGllck5HQUdyaWQgLT4gZ3ZfY2F0YWxvZw0KMTM6Mjc6MjIsMDAw
ICBJTkZPIENvbmZpZ3VyYXRpb246NDYwIC0gUmVhZGluZyBtYXBwaW5ncyBmcm9tIHJlc291cmNl
OiBHcm91cC5oYm0ueG1sDQoxMzoyNzoyMiwwMTUgIElORk8gSGJtQmluZGVyOjMxMSAtIE1hcHBp
bmcgY2xhc3M6IGNvbS5pbnNlcXVlbmNlLmd2Lkdyb3VwIC0+IGd2X2dyb3VwDQoxMzoyNzoyMiww
MTUgIElORk8gQ29uZmlndXJhdGlvbjo0NjAgLSBSZWFkaW5nIG1hcHBpbmdzIGZyb20gcmVzb3Vy
Y2U6IE9yZGVyLmhibS54bWwNCjEzOjI3OjIyLDAxNSAgSU5GTyBIYm1CaW5kZXI6MzExIC0gTWFw
cGluZyBjbGFzczogY29tLmluc2VxdWVuY2UuZ3YuT3JkZXIgLT4gZ3Zfb3JkZXINCjEzOjI3OjIy
LDAxNSAgSU5GTyBDb25maWd1cmF0aW9uOjQ2MCAtIFJlYWRpbmcgbWFwcGluZ3MgZnJvbSByZXNv
dXJjZTogTmV3T3JkZXIuaGJtLnhtbA0KMTM6Mjc6MjIsMDMxICBJTkZPIEhibUJpbmRlcjozMTEg
LSBNYXBwaW5nIGNsYXNzOiBjb20uaW5zZXF1ZW5jZS5ndi5OZXdPcmRlciAtPiBndl9uZXdfb3Jk
ZXINCjEzOjI3OjIyLDAzMSAgSU5GTyBDb25maWd1cmF0aW9uOjQ2MCAtIFJlYWRpbmcgbWFwcGlu
Z3MgZnJvbSByZXNvdXJjZTogUHJvZHVjdC5oYm0ueG1sDQoxMzoyNzoyMiwwMzEgIElORk8gSGJt
QmluZGVyOjMxMSAtIE1hcHBpbmcgY2xhc3M6IGNvbS5pbnNlcXVlbmNlLmd2LlByb2R1Y3QgLT4g
Z3Zfc3VwcGxpZXJzDQoxMzoyNzoyMiwwMzEgIElORk8gQ29uZmlndXJhdGlvbjo0NjAgLSBSZWFk
aW5nIG1hcHBpbmdzIGZyb20gcmVzb3VyY2U6IFByb2R1Y3RPcmRlci5oYm0ueG1sDQoxMzoyNzoy
MiwwMzEgIElORk8gSGJtQmluZGVyOjMxMSAtIE1hcHBpbmcgY2xhc3M6IGNvbS5pbnNlcXVlbmNl
Lmd2LlByb2R1Y3RPcmRlciAtPiBndl9wcm9kdWN0X29yZGVyDQoxMzoyNzoyMiwwMzEgIElORk8g
Q29uZmlndXJhdGlvbjo0NjAgLSBSZWFkaW5nIG1hcHBpbmdzIGZyb20gcmVzb3VyY2U6IFN1cHBs
aWVyQ3VzdG9tZXJBY2Nlc3MuaGJtLnhtbA0KMTM6Mjc6MjIsMDQ2ICBJTkZPIEhibUJpbmRlcjoz
MTEgLSBNYXBwaW5nIGNsYXNzOiBjb20uaW5zZXF1ZW5jZS5ndi5TdXBwbGllckN1c3RvbWVyQWNj
ZXNzIC0+IGd2X3N1cHBsaWVyX2N1c3RvbWVyX2FjY2Vzcw0KMTM6Mjc6MjIsMDQ2ICBJTkZPIENv
bmZpZ3VyYXRpb246NDYwIC0gUmVhZGluZyBtYXBwaW5ncyBmcm9tIHJlc291cmNlOiBVc2VyLmhi
bS54bWwNCjEzOjI3OjIyLDA0NiAgSU5GTyBIYm1CaW5kZXI6MzExIC0gTWFwcGluZyBjbGFzczog
Y29tLmluc2VxdWVuY2UuZ3YuVXNlciAtPiBndl91c2VyDQoxMzoyNzoyMiwwNDYgIElORk8gQ29u
ZmlndXJhdGlvbjo0NjAgLSBSZWFkaW5nIG1hcHBpbmdzIGZyb20gcmVzb3VyY2U6IFN0cnVjdHVy
ZS5oYm0ueG1sDQoxMzoyNzoyMiwwNjIgIElORk8gSGJtQmluZGVyOjMxMSAtIE1hcHBpbmcgY2xh
c3M6IGNvbS5pbnNlcXVlbmNlLmd2LlN0cnVjdHVyZSAtPiBndl9zdHJ1Y3R1cmUNCjEzOjI3OjIy
LDA2MiAgSU5GTyBDb25maWd1cmF0aW9uOjEzNTAgLSBDb25maWd1cmVkIFNlc3Npb25GYWN0b3J5
OiBudWxsDQo=

[Hibernate] JPA Question : Deletion w.r.t One-to-many relation

[The R. <the...@gm...>]

Hi,

Am a newbie to Java Persistence API. In our database, we have a one-to-many
relationship between 2 tables, say t1 & t2 i.e. one record of t1 can be
associated with multiple records in table t2. Is it possible to delete a row
in t2 without doing anything to the associated row in t1? Is this allowed in
JPA? I heard that an error saying "parent is null' is thrown in such a case?

Thanks.

Re: [Hibernate] confirm 9450b97270917ddaf59faa6fb2a16df9d93669e3

[Yu D. <yud...@gm...>]

Query:
1. from invItem c where c.regularDoc is null; ---no rows return, should be a
large number of rows
2. from invItem c where c.regularDoc is not null; --- returned the correct
rows, cast (InvDecalItem) to get the rows.
3. from invItem c left join c.regularDoc doc where doc is null; --- returned
rows, but I got cast exception (I cast the row to (InvDecalItem) as well as
(InvItem) type) when I want to get row information.
4. from invItem c left join c.regularDoc doc where doc is not null; ---
returned rows, the same as 3.

I think of using join, I want to know that how to cast the result rows?


below are related definations and classes:

<hibernate-mapping>
    <class name="InvItem">
    <id name="id" column="id">
           <generator class="hilo"/>
        </id>
    <discriminator column="invType" length="1"/>
    <many-to-one name="transferredDetails"/> <!-- FK: Points to
corresponding entry for transferred inventory items -->
    <subclass name="InvDecalItem" discriminator-value='D'>
        <one-to-one  name="regularDoc" property-ref="decalNew"
access="field" /> <!-- nullable: an item maybe not attach to a document -->
    </subclass>
    </class>
</hibernate-mapping>


</hibernate-mapping>
    <class name="AbstractRegularDoc" table="RegularDoc">
        <id name="id">
           <generator class="hilo"/>
        </id>
    <many-to-one name="decalNew" index="decalIdx" access="field"
unique="true"/>
     </class>
</hibernate-mapping>



public abstract class AbstractRegularDoc{
    private InvDecalItem decalNew;
        ...
    public InvDecalItem getDecalNew()

    {

        return decalNew;

    }


    public void setDecalNew(InvDecalItem decalNewParam)

    {

        if (decalNewParam != null)

            decalNewParam.setRegularDoc(this);

    }
}



public class InvDecalItem extends InvItem
{
    private AbstractRegularDoc regularDoc;

    public AbstractRegularDoc getRegularDoc()

    {

        return regularDoc;

         }


    public void setRegularDoc(AbstractRegularDoc regulardocs)

    {
         if (this.regularDoc != null)

            this.regularDoc.setDecalNew(this);

    }
}

[Hibernate] questions about query of join

[Yu D. <yud...@gm...>]

Query:
1. from invItem c where c.regularDoc is null; ---no rows return, should be a
large number of rows
2. from invItem c where c.regularDoc is not null; --- returned the correct
rows, cast (InvDecalItem) to get the rows.
3. from invItem c left join c.regularDoc doc where doc is null; --- returned
rows, but I got cast exception (I cast the row to (InvDecalItem) as well as
(InvItem) type) when I want to get row information.
4. from invItem c left join c.regularDoc doc where doc is not null; ---
returned rows, the same as 3.

I think of using join, I want to know that how to cast the result rows?


<hibernate-mapping>
    <class name="InvItem">
    <id name="id" column="id">
           <generator class="hilo"/>
        </id>
    <discriminator column="invType" length="1"/>
    <many-to-one name="transferredDetails"/> <!-- FK: Points to
corresponding entry for transferred inventory items -->
    <subclass name="InvDecalItem" discriminator-value='D'>
        <one-to-one  name="regularDoc" property-ref="decalNew"
access="field" /> <!-- nullable: an item maybe not attach to a document -->
    </subclass>
    </class>
</hibernate-mapping>


</hibernate-mapping>
    <class name="AbstractRegularDoc" table="RegularDoc">
        <id name="id">
           <generator class="hilo"/>
        </id>
    <many-to-one name="decalNew" index="decalIdx" access="field"
unique="true"/>
     </class>
</hibernate-mapping>



public abstract class AbstractRegularDoc{
    private InvDecalItem decalNew;
        ...
    public InvDecalItem getDecalNew()

    {

        return decalNew;

    }


    public void setDecalNew(InvDecalItem decalNewParam)

    {

        if (decalNewParam != null)

            decalNewParam.setRegularDoc(this);

    }
}



public class InvDecalItem extends InvItem
{
    private AbstractRegularDoc regularDoc;

    public AbstractRegularDoc getRegularDoc()

    {

        return regularDoc;

         }


    public void setRegularDoc(AbstractRegularDoc regulardocs)

    {
         if (this.regularDoc != null)

            this.regularDoc.setDecalNew(this);

    }
}

Re: [Hibernate] Selecting rows only from a particular table

[The R. <the...@gm...>]

Thanks to all for your replies. Lazy loading does the trick!



On 4/24/07, Dmitri Colebatch <di...@co...> wrote:
>
> Hi,
>
> I think you'd be better off here: http://forum.hibernate.org/
>
> The answer to your question is lazy loading, see http://www.hibernate.org/hib_docs/v3/reference/en/html/performance.html#performance-fetching-lazy
>
>
> cheers,
> dim
>
>
>  On 4/23/07, The Rhythmic <the...@gm...> wrote:
>
> >  Hi,
> >
> > Am using Hibernate with Java Persistence API.
> >
> > The question, in short is:
> > How do I restrict the Java Persistence API to access rows only from one
> > table & not from any other table i.e. Even though it might require
> > access to other tables, it should access rows only from one particular
> > table. How to enforce this?
> >
> > In detail, this' the problem:
> >
> > We have a data model like this:
> >
> > Level 1 class
> > ......within this there is Level 2 class
> > ............within Level 2, there is Level 3 class
> >
> > it's just like XML data where we have a tag within another tag & so on.
> > The root tag is Level1 & the tags in the next level are Level2, let's
> > assume...and so on.
> >
> > i.e. an instance of Level1 class can contain many objects of Level2
> > within it. And an instance of Level2 class can contain many objects of
> > Level3 within it. Within the Level1 class, we have methods to fetch
> > corresponding objects from Level2. & the same for Level2 class. So, using
> > Java Persistence API, when accessing instances of Level1, they automatically
> > fetch corresponding instances of Level2 & Level3. Level1 has a corresponding
> > table in the database called Level1. & the same with Level2 & Level3. How do
> > I restrict the Java Persistence API to fetch objects only from Level1 table
> > & not from other tables?
> >
> > Thanks.
> >
> >
> > -------------------------------------------------------------------------
> > This SF.net email is sponsored by DB2 Express
> > Download DB2 Express C - the FREE version of DB2 express and take
> > control of your XML. No limits. Just data. Click to get it now.
> > http://sourceforge.net/powerbar/db2/
> > _______________________________________________
> > hibernate-devel mailing list
> > hib...@li...
> > https://lists.sourceforge.net/lists/listinfo/hibernate-devel
> >
> >
>

Re: [Hibernate] Selecting rows only from a particular table

[Dmitri C. <di...@co...>]

Hi,

I think you'd be better off here: http://forum.hibernate.org/

The answer to your question is lazy loading, see
http://www.hibernate.org/hib_docs/v3/reference/en/html/performance.html#performance-fetching-lazy

cheers,
dim


On 4/23/07, The Rhythmic <the...@gm...> wrote:
>
> Hi,
>
> Am using Hibernate with Java Persistence API.
>
> The question, in short is:
> How do I restrict the Java Persistence API to access rows only from one
> table & not from any other table i.e. Even though it might require access
> to other tables, it should access rows only from one particular table. How
> to enforce this?
>
> In detail, this' the problem:
>
> We have a data model like this:
>
> Level 1 class
> ......within this there is Level 2 class
> ............within Level 2, there is Level 3 class
>
> it's just like XML data where we have a tag within another tag & so on.
> The root tag is Level1 & the tags in the next level are Level2, let's
> assume...and so on.
>
> i.e. an instance of Level1 class can contain many objects of Level2 within
> it. And an instance of Level2 class can contain many objects of Level3
> within it. Within the Level1 class, we have methods to fetch corresponding
> objects from Level2. & the same for Level2 class. So, using Java Persistence
> API, when accessing instances of Level1, they automatically fetch
> corresponding instances of Level2 & Level3. Level1 has a corresponding table
> in the database called Level1. & the same with Level2 & Level3. How do I
> restrict the Java Persistence API to fetch objects only from Level1 table &
> not from other tables?
>
> Thanks.
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> hibernate-devel mailing list
> hib...@li...
> https://lists.sourceforge.net/lists/listinfo/hibernate-devel
>
>

[Hibernate] Selecting rows only from a particular table

[The R. <the...@gm...>]

Hi,

Am using Hibernate with Java Persistence API.

The question, in short is:
How do I restrict the Java Persistence API to access rows only from one
table & not from any other table i.e. Even though it might require access to
other tables, it should access rows only from one particular table. How
to enforce this?

In detail, this' the problem:

We have a data model like this:

Level 1 class
......within this there is Level 2 class
............within Level 2, there is Level 3 class

it's just like XML data where we have a tag within another tag & so on. The
root tag is Level1 & the tags in the next level are Level2, let's
assume...and so on.

i.e. an instance of Level1 class can contain many objects of Level2 within
it. And an instance of Level2 class can contain many objects of Level3
within it. Within the Level1 class, we have methods to fetch corresponding
objects from Level2. & the same for Level2 class. So, using Java Persistence
API, when accessing instances of Level1, they automatically fetch
corresponding instances of Level2 & Level3. Level1 has a corresponding table
in the database called Level1. & the same with Level2 & Level3. How do I
restrict the Java Persistence API to fetch objects only from Level1 table &
not from other tables?

Thanks.

[Hibernate] Using Hibernate with Java Persistence API

[The R. <the...@gm...>]

Hi, Can someone point me to some good tutorial about using Hibernate in
conjuction with the Java Persistence API. I use the Eclipse IDE. Thanks.

Re: [Hibernate] Getting mapped table name to a persistent object

[Jordan <jo...@re...>]

As the Hibernate devs will often sarcastically remind you, the dev list =
is NOT a user forum. Check hibernate.org for a link to the forums, where =
people are more apt to help.

That said, access to mapping information for a persistent class is =
usually done through the SessionFactory. In Hibernate 2 one goes:

SessionFactory factory =3D *YOUR SESSION FACTORY*
Class cls =3D *YOUR PERSISTENT OBJECT CLASS*
BasicEntityPersister classMetadata =3D =
(BasicEntityPersister)factory.getClassMetadata(cls);

Once you have access to classMetaData, you can get the table name =
through:

classMetadata.getTableName()

-JL

----- Original Message -----=20
  From: Hess Yvan=20
  To: hib...@li...=20
  Sent: Tuesday, March 20, 2007 3:46 AM
  Subject: [Hibernate] Getting mapped table name to a persistent object


  Hi,

  I am using Hibernate V 2.1.8, and I have to do a bulk update using a =
direct SQL connection. This is due to the fact that Hibernate V2.1.8 =
doesn't support Query.update(). As the database mapping table can change =
into my Hibernate mapping, I would like to retrieve it dynamicly.=20

  How can retrieve the name of the database table that is used to store =
a given persisent object ?

  Thanks for your answer.

  Regards. Yvan Hess

  Yvan Hess

  Chief Software Architect




  e-mail: yva...@im...
  phone : +41 (0)26 460 66 66=20
  fax   : +41 (0)26 460 66 60=20



  Informatique-MTF SA
  Route du Bleuet 1=20
  CH-1762 Givisiez=20

  Excellence in Compliance and Document Management

  http://www.imtf.com



  DISCLAIMER=20
  This message is intended only for use by the person to whom it is =
addressed. It may contain information that is privileged and =
confidential. Its content does not constitute a formal commitment by =
IMTF. If you are not the intended recipient of this message, kindly =
notify the sender immediately and destroy this message. Thank You.




-------------------------------------------------------------------------=
-----


  =
-------------------------------------------------------------------------=

  Take Surveys. Earn Cash. Influence the Future of IT
  Join SourceForge.net's Techsay panel and you'll get the chance to =
share your
  opinions on IT & business topics through brief surveys-and earn cash
  =
http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D=
DEVDEV


-------------------------------------------------------------------------=
-----


  _______________________________________________
  hibernate-devel mailing list
  hib...@li...
  https://lists.sourceforge.net/lists/listinfo/hibernate-devel

[Hibernate] Getting mapped table name to a persistent object

[Hess Y. <Yva...@im...>]

Hi,
=20
I am using Hibernate V 2.1.8, and I have to do a bulk update using a
direct SQL connection. This is due to the fact that Hibernate V2.1.8
doesn't support Query.update(). As the database mapping table can change
into my Hibernate mapping, I would like to retrieve it dynamicly.=20
=20
How can retrieve the name of the database table that is used to store a
given persisent object ?
=20
Thanks for your answer.
=20
Regards. Yvan Hess
=20
Yvan Hess

Chief Software Architect

=20

e-mail: yva...@im...
phone : +41 (0)26 460 66 66=20
fax   : +41 (0)26 460 66 60=20

=20

Informatique-MTF SA
Route du Bleuet 1=20
CH-1762 Givisiez=20

Excellence in Compliance and Document Management

http://www.imtf.com <http://www.imtf.com/>=20

=20

DISCLAIMER=20
This message is intended only for use by the person to whom it is
addressed. It may contain information that is privileged and
confidential. Its content does not constitute a formal commitment by
IMTF. If you are not the intended recipient of this message, kindly
notify the sender immediately and destroy this message. Thank You.

=20

Re: [Hibernate] Problems compiling hbm2dao generated code

[Francesco P. <ce...@gm...>]

2007/3/19, Max Rydahl Andersen <max...@re...>:
>
> jdk5 does autoboxing, older jdk's does not.
>
> So int into an Integer fails.
>

(please note i'm an unexperienced java dev)
I produced the patch (using "svn diff"), at least it compiles now.
Probably the same function toWrapperClass() in BasicPOJOClass.java is
not needed but i didn't understand how it does work getJavaTypeClass
in that class so i was more conservative (you surely know how to cut
it and retain only the version of Cfg2JavaTool.java).

I have 2 more question, if you have time to respond me:
1) Now that compiles, can i trust this interface? Is there some usage
documentation about it (can't found it in hibernate manuals)?
2) I see that a "List findAll()" method is not provided (sort of
"select * from Table"). How can i obtain it in the right (and quick)
way?

For the patch, if it's ok, license is obviously lgpl and i give the
copyright to you.

Thanks,
Francesco

Re: [Hibernate] Problems compiling hbm2dao generated code

[Francesco P. <ce...@gm...>]

2007/3/19, Max Rydahl Andersen <max...@re...>:
>
> I'ts always been the case. Feel free to submit a patch; but the dao
> generation
> has and still is considered "in progress".
>
> /max
>

Ok, i can take a look at the dao generation templates (i extremely
need it). If i succeed, i can surely send a patch. But please, can you
point me to the reason it doesn't compile? Maybe i'm blind, but i
can't understand why it doesn't.

This is the incriminated dao interface:
http://www.webalice.it/ceztko/ProvinciaHome.java

Thanks,

Francesco

Re: [Hibernate] Problems compiling hbm2dao generated code

[Francesco P. <ce...@gm...>]

2007/3/19, Max Rydahl Andersen <max...@re...>:
> answered in tools forum many times before.
>
> use jdk5 to compile or use latest version of tools.
>
> /max
>
>

Compiled latest version from
http://anonsvn.jboss.org/repos/hibernate/branches/Branch_3_2/HibernateExt
(where appears to be the latest development), and the code is still
uncompilable by jdk 1.4. Unfortunately, i'm constrained to jdk 1.4 for
my project. However, Isn't this a bug (or a regression), also
considering that the default parameter for jdk5 is "false"?

Francesco

[Hibernate] Problems compiling hbm2dao generated code

[Francesco P. <ce...@gm...>]

I'm sorry to post on dev list for this that probably is a user
problem, but i got no feedback on user forum, and google has no answer
for this strange problem.

Hibernate version: 3.2.2
JDK: 1.4

The problem: i was able to generate and compile pojos files with
hbm2java ant target but trying to compile dao interfaces (created with
hbm2dao) i got a bunch of these:

/home/ceztko/development/thgroup/visionehrcv/src/com/thgroup/visionehrcv/model/StatoValutazioneHome.java:99:
cannot resolve symbol
symbol  : method get (java.lang.String,int)
location: interface org.hibernate.classic.Session
            StatoValutazione instance = (StatoValutazione)
sessionFactory.getCurrentSession().get("com.thgroup.visionehrcv.model.StatoValutazione",
id);
                                                          ^

The same error is on all dao classes, all at line 99. My classpath is
ok (surely it see hibernate3.jar, most recent stable version). Trying
to recompile hibernate3 from source, and trying to recompile the
project with all hibernate3 source bundled libs in the classpath give
me the same error.
Looked hibernate sources and get method with parameters String and int
is there, in the org.hibernate.Session superclass! So seems no problem
there too...

Here you can find an example class of the generated sources, pojo
(that compile) and daos (that doesn't), and the config.hbm.xml:
    http://www.webalice.it/ceztko/Provincia.java
    http://www.webalice.it/ceztko/ProvinciaHome.java
    http://www.webalice.it/ceztko/config.hbm.xml

Thanks for your attention. Forgive me if was a my oversight.

Francesco