[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [eclipselink-users] Specifying CASCADE-REMOVE in project.xml
|
Hi Miguel,
The project.xml works independently, so unfortunately orm.xml and
eclipselink-orm.xml cannot be used to override settings in it.
With orm.xml or eclipselink-orm.xml you would have to specify all the
settings that differ from the JPA defaults - so depending on your object model,
this could be either very little, of quite a bit.
-Tom
Miguel Morales wrote:
Tom,
just started developing with dynamic persistence last week, doing very
well, thanks. Since you know this stuff so well, can you confirm that
if I want to solve the cascade issue by using orm or eclipselink-orm I
would have to specify the entire descriptor info and not just the
cascade option ? Any chance it will read the descriptor info from
project.xml and apply a single attribute (CASCADE) it finds in either of
the two previous xml files mentioned? That would be the best solution.
Miguel
--------------------------------------------------
From: "Tom Ware" <tom.ware@xxxxxxxxxx>
Sent: Monday, November 08, 2010 9:29 PM
To: "EclipseLink User Discussions" <eclipselink-users@xxxxxxxxxxx>
Subject: Re: [eclipselink-users] Specifying CASCADE-REMOVE in project.xml
Hi Miguel,
You are correct that if you have a large amount of metadata already
mapped, the path of least resistance will likely be using the preLogin
event.
The other option, as you have remarked is a conversion to
eclipselink-orm.xml. It covers the majority of the features
available through project.xml and also covers the new features
introduced in JPA. It will be the main xml-based target for new
configuration options we add in the future. In JPA, you get alot for
free because of the defaulting, so depending on how your model is
designed you get alot for free.
BTW: In case you are not aware, we have a feature that allows
dynamic generation of Entities. Here's an example:
http://wiki.eclipse.org/EclipseLink/Examples/JPA/Dynamic
-Tom
Miguel Morales wrote:
Tom,
the Eclipselink Workbench seemed like a more practical interface than
Dali in Eclipse, although later I discovered that it has missing
features. But I simply cannot afford embedded annotations because my
application will be generating dynamic entities and database
features, and I want to keep all configuration outside of the code
itself. I was just considering the ORM.XML option when I saw your
email, as it is possible to override configurations using that file
and the eclipselink-orm.xml (something like that). But it would
force me to specify the entire configuration for that entity just to
be able to add the cascade feature I need. As much as possible I
would like a single point for generating all necessary JPA stuff, the
eclipse workbench, but barring that I want the least involved option,
which at this point I believe would be your suggestion to use the
preLogin. I will look into it, thank you.
Miguel
--------------------------------------------------
From: "Tom Ware" <tom.ware@xxxxxxxxxx>
Sent: Monday, November 08, 2010 8:42 PM
To: "EclipseLink User Discussions" <eclipselink-users@xxxxxxxxxxx>
Subject: Re: [eclipselink-users] Specifying CASCADE-REMOVE in
project.xml
Is your objection to annotations, or to JPA metadata in general?
If you are are looking for an xml-based way of specifying your
metadata, JPA allows you to fully specify the metadata in orm.xml
files. You can use the Eclipse Dali project for tooling. orm.xml
provides equivalent functionality to what is available in annotations.
If you would like to keep using project.xml, your best bet is to
modify your mappings through API in an event. I suggest using the
preLogin event to modify your descriptors. You can call
setCascadeRemove(true) on each ForeignReferenceMapping you would
like cascade remove to operate on.
-Tom
rmmora159 wrote:
I need a way to specify a CASCADE-REMOVE setting on a one-to-many
relationship in the project.xml of my eclipselink app. Currently a
remove()
on the parent entity throws an SQL exception because of the foreign
key
constraint. I know this is easily solved using annotations, but I
DO NOT
use annotations nor will I use them because they are a waste of
time. It is
much more efficient to use a single project.xml that describes
everything. Furthermore, my application generates its own database
tables and entities,
so I need to keep everything as centralized and hands-free as
possible. I
use the eclipse Workbench (I know, I shouldn't) to generate all the
necessary components, but that GUI does not seem to have an option
to set
cascading type for relationships. I know I'll probably have to
manually add
the CASCADE setting to the project.xml, but I cannot figure out the
xsd
specifications to correctly insert it into the xml. I could also
take care
of the problem in java before calling the remove() method of the
EntityManager, if someone knows how to do so.
_______________________________________________
eclipselink-users mailing list
eclipselink-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-users
_______________________________________________
eclipselink-users mailing list
eclipselink-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-users
_______________________________________________
eclipselink-users mailing list
eclipselink-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-users
_______________________________________________
eclipselink-users mailing list
eclipselink-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-users
