8:08 a.m.
Hey,
Last week I "fixed" Hibernate tools by adding support for controlling cascade,
insert, update and a few other things on associations.
In that progress I noticed that the reverse engineering were setting all collection
associations cascade to "all" and not "none" which I believe would be
the better to avoid surprises.
I changed it to 'none' since our hbm.xml generation were not generating cascade at
that point anyway, but of course when coming to seam-gen we use annotations and in here
CascadeType.ALL were being output - with the new hibernate tools no cascade is set because
CascadeType.NONE is the default.
This is of course a change in the semantics of generation and I just want to check what we
would *really* like to do...
1) does this change actually break seam-gen in any way ? (I don't think so because all
assocations is explicitly updated anyway (afaics))
2) What default do you think we should use for reveng, ALL or NONE (or something else ?)
p.s. A swift reply would be appreciated since we are going for a GA build within a few
days ;)
p.p.s. If we find a better default I can add a checkbox in the tools to enable to old
default if needed.
p.p.p.s. For Pete: The bug I mentioned last night was simply another indentifier
misspelling we found that for some
reason hadn't been patched in our build - so that is a separate issue I'm trying
to find the cause for in https://jira.jboss.org/jira/browse/JBIDE-3880
Thanks,
Max
12:54 p.m.
On Tue, Mar 3, 2009 at 8:10 AM, Emmanuel Bernard <emmanuel(a)hibernate.org>wrote:
On Feb 28, 2009, at 08:08, Max Rydahl Andersen wrote:
> 2) What default do you think we should use for reveng, ALL or NONE (or
> something else ?)
>
none
What about PERSIST? I really like to be able to do this.
Child c1 = new Child();
Child c2 = new Child();
Parent p = new Parent();
p.addChild(c1);
p.addChild(c2);
em.persist(p);
With none, you have to go through and do persists all over the place...and
in a real application, that top level object typically has 10+
relationships, esp if lookup tables are used.
-Dan
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
http://mojavelinux.com
http://mojavelinux.com/seaminaction
NOTE: While I make a strong effort to keep up with my email on a daily
basis, personal or other work matters can sometimes keep me away
from my email. If you contact me, but don't hear back for more than a week,
it is very likely that I am excessively backlogged or the message was
caught in the spam filters. Please don't hesitate to resend a message if
you feel that it did not reach my attention.
2:12 p.m.
If I am put my 5 cents (inflation). My personal default is (PERSIST, MERGE,
REFRESH) and in the circumstance that I need to put a DELETE then I would if
necessary. I assume beginner Seam developers would absolutely freak if they
saw a detached entity exceptions when they first use Seam's reveng.
On Wed, Mar 4, 2009 at 10:54 AM, Dan Allen <dan.j.allen(a)gmail.com> wrote:
On Tue, Mar 3, 2009 at 8:10 AM, Emmanuel Bernard <emmanuel(a)hibernate.org>wrote:
>
> On Feb 28, 2009, at 08:08, Max Rydahl Andersen wrote:
>
>
>> 2) What default do you think we should use for reveng, ALL or NONE (or
>> something else ?)
>>
>
> none
What about PERSIST? I really like to be able to do this.
Child c1 = new Child();
Child c2 = new Child();
Parent p = new Parent();
p.addChild(c1);
p.addChild(c2);
em.persist(p);
With none, you have to go through and do persists all over the place...and
in a real application, that top level object typically has 10+
relationships, esp if lookup tables are used.
-Dan
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
http://mojavelinux.com
http://mojavelinux.com/seaminaction
NOTE: While I make a strong effort to keep up with my email on a daily
basis, personal or other work matters can sometimes keep me away
from my email. If you contact me, but don't hear back for more than a week,
it is very likely that I am excessively backlogged or the message was
caught in the spam filters. Please don't hesitate to resend a message if
you feel that it did not reach my attention.
_______________________________________________
seam-dev mailing list
seam-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev
--
Daniel Hinojosa
Programmer, Instructor, and Consultant
2529 Wisconsin St. NE
Albuquerque, NM 87110
dhinojosa(a)evolutionnext.com
http://www.evolutionnext.com
http://www.abqjug.org
(505) 363-5832
2:34 p.m.
On Wed, Mar 4, 2009 at 2:12 PM, Daniel Hinojosa <dhinojosa(a)evolutionnext.com
wrote:
If I am put my 5 cents (inflation). My personal default is
(PERSIST,
MERGE, REFRESH) and in the circumstance that I need to put a DELETE then I
would if necessary. I assume beginner Seam developers would absolutely
freak if they saw a detached entity exceptions when they first use Seam's
reveng.
Thanks for reminding me of the DELETE use case Dan. No question that is the
most important one, even more than PERSIST.
I pretend that MERGE doesn't exist because I personally I detest it. REFRESH
makes sense, though few new comers would run into it. Perhaps we can go with
PERSIST, DELETE, REFRESH
-Dan
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
http://mojavelinux.com
http://mojavelinux.com/seaminaction
NOTE: While I make a strong effort to keep up with my email on a daily
basis, personal or other work matters can sometimes keep me away
from my email. If you contact me, but don't hear back for more than a week,
it is very likely that I am excessively backlogged or the message was
caught in the spam filters. Please don't hesitate to resend a message if
you feel that it did not reach my attention.
2:17 p.m.
Then add @*to*(cascade=CascadeType.PERSIST), it will take you 2 mins
to do what you really like and you will know you do it.
Or even faster, add the stupid
<entity-mappings>
<persistence-unit-metadata>
<persistence-unit-defaults>
<cascade-persist/>
</persistence-unit-defaults>
</persistence-unit-metadata>
</entity-mappings>
in your orm.xml file and you are good to go.
I really like smoking Chicha when drinking tea. Not sure it should be
enforced to everyone. Not sure if I should do it every time either.
On Mar 4, 2009, at 12:54, Dan Allen wrote:
On Tue, Mar 3, 2009 at 8:10 AM, Emmanuel Bernard <emmanuel(a)hibernate.org
> wrote:
On Feb 28, 2009, at 08:08, Max Rydahl Andersen wrote:
2) What default do you think we should use for reveng, ALL or NONE
(or something else ?)
none
What about PERSIST? I really like to be able to do this.
Child c1 = new Child();
Child c2 = new Child();
Parent p = new Parent();
p.addChild(c1);
p.addChild(c2);
em.persist(p);
With none, you have to go through and do persists all over the
place...and in a real application, that top level object typically
has 10+ relationships, esp if lookup tables are used.
-Dan
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
http://mojavelinux.com
http://mojavelinux.com/seaminaction
NOTE: While I make a strong effort to keep up with my email on a daily
basis, personal or other work matters can sometimes keep me away
from my email. If you contact me, but don't hear back for more than
a week,
it is very likely that I am excessively backlogged or the message was
caught in the spam filters. Please don't hesitate to resend a
message if
you feel that it did not reach my attention.
2:38 p.m.
On Wed, Mar 4, 2009 at 2:17 PM, Emmanuel Bernard <emmanuel(a)hibernate.org>wrote:
Then add @*to*(cascade=CascadeType.PERSIST), it will take you 2 mins
to do
what you really like and you will know you do it.
It doesn't take two minutes when you have 80 entities. Most apps have large
databases. Rarely do you see simple schemas like we have in the examples.
When you generate your entities again and have to start all over. I think
this is a good default to have, as well as DELETE and maybe REFRESH. Daniel
can speak better to what he is seeing out in the field.
NONE is a crappy default.
-Dan
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
http://mojavelinux.com
http://mojavelinux.com/seaminaction
NOTE: While I make a strong effort to keep up with my email on a daily
basis, personal or other work matters can sometimes keep me away
from my email. If you contact me, but don't hear back for more than a week,
it is very likely that I am excessively backlogged or the message was
caught in the spam filters. Please don't hesitate to resend a message if
you feel that it did not reach my attention.
2:59 p.m.
class Address {
@ManyToOne Country country;
@ManyToOne State state;
@ManyToMany Set<Person> inhabitants;
}
It generally makes no sense to cascade persist for these three
associations. Even if your app has 80 entities, it's very likely that
half of the associations should not be cascaded :)
Let's take your proposal
PERSIST, DELETE, REFRESH
I REFRESH address and changes on Person are lost, doh!
PERSIST, do I really save an address and expect the person living
there to be added to the system. Surely not, the person is very likely
to have been built beforehand. Same for Country and State.
MERGE Do I really want to update a country when an address changes? I
can't find a system that would do that.
Cascade has performance consequences. The more cascades the slower
your app will be at flush time. Especially on applications with a lot
of entities.
NONE is a good default, that's why it's the default we have chosen :)
On Mar 4, 2009, at 14:38, Dan Allen wrote:
On Wed, Mar 4, 2009 at 2:17 PM, Emmanuel Bernard
<emmanuel(a)hibernate.org
> wrote:
Then add @*to*(cascade=CascadeType.PERSIST), it will take you 2 mins
to do what you really like and you will know you do it.
It doesn't take two minutes when you have 80 entities. Most apps
have large databases. Rarely do you see simple schemas like we have
in the examples. When you generate your entities again and have to
start all over. I think this is a good default to have, as well as
DELETE and maybe REFRESH. Daniel can speak better to what he is
seeing out in the field.
NONE is a crappy default.
-Dan
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
http://mojavelinux.com
http://mojavelinux.com/seaminaction
NOTE: While I make a strong effort to keep up with my email on a daily
basis, personal or other work matters can sometimes keep me away
from my email. If you contact me, but don't hear back for more than
a week,
it is very likely that I am excessively backlogged or the message was
caught in the spam filters. Please don't hesitate to resend a
message if
you feel that it did not reach my attention.
3:11 p.m.
On Wed, Mar 4, 2009 at 2:59 PM, Emmanuel Bernard <emmanuel(a)hibernate.org>wrote:
class Address { @ManyToOne Country country;
@ManyToOne State state;
@ManyToMany Set<Person> inhabitants;
}
It generally makes no sense to cascade persist for these three
associations. Even if your app has 80 entities, it's very likely that half
of the associations should not be cascaded :)
Let's take your proposal
PERSIST, DELETE, REFRESH
I REFRESH address and changes on Person are lost, doh!
True. I was on the fence about REFRESH. I think you convinced me.
PERSIST, do I really save an address and expect the person living
there to
be added to the system. Surely not, the person is very likely to have been
built beforehand. Same for Country and State.
Not a problem if County and State are managed, which is likely how you
attach them anyway. It will even work if they are a non-managed entity with
a valid ID. If neither of those are the case, then yes, I want the persist
to add them to the database. That's the whole point of the cascade.
MERGE Do I really want to update a country when an address changes? I
can't
find a system that would do that.
I don't do MERGE, so I don't care.
Cascade has performance consequences. The more cascades the slower
your app
will be at flush time. Especially on applications with a lot of entities.
NONE is a good default, that's why it's the default we have chosen :)
I'm still don't agree. I like PERSIST and DELETE. DELETE can be dangerous,
but it's also extremely convenient.
-Dan
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
http://mojavelinux.com
http://mojavelinux.com/seaminaction
NOTE: While I make a strong effort to keep up with my email on a daily
basis, personal or other work matters can sometimes keep me away
from my email. If you contact me, but don't hear back for more than a week,
it is very likely that I am excessively backlogged or the message was
caught in the spam filters. Please don't hesitate to resend a message if
you feel that it did not reach my attention.
5:05 p.m.
Convenient does not mean it should be default.
Anyway, for GA we will keep the "old" default since it was discovered
too late.
Then when we do have the ui for controlling the default I would just
have a few options but
let none be the default since it is the less risky one and you can set
the default option in persistence.xml
instead of going set it on every single entity.
/max
On Wed, Mar 4, 2009 at 2:59 PM, Emmanuel Bernard
<emmanuel(a)hibernate.org <mailto:emmanuel@hibernate.org>> wrote:
class Address {
@ManyToOne Country country;
@ManyToOne State state;
@ManyToMany Set<Person> inhabitants;
}
It generally makes no sense to cascade persist for these three
associations. Even if your app has 80 entities, it's very likely
that half of the associations should not be cascaded :)
Let's take your proposal
PERSIST, DELETE, REFRESH
I REFRESH address and changes on Person are lost, doh!
True. I was on the fence about REFRESH. I think you convinced me.
PERSIST, do I really save an address and expect the person living
there to be added to the system. Surely not, the person is very
likely to have been built beforehand. Same for Country and State.
Not a problem if County and State are managed, which is likely how you
attach them anyway. It will even work if they are a non-managed entity
with a valid ID. If neither of those are the case, then yes, I want
the persist to add them to the database. That's the whole point of the
cascade.
MERGE Do I really want to update a country when an address
changes? I can't find a system that would do that.
I don't do MERGE, so I don't care.
Cascade has performance consequences. The more cascades the slower
your app will be at flush time. Especially on applications with a
lot of entities.
NONE is a good default, that's why it's the default we have chosen :)
I'm still don't agree. I like PERSIST and DELETE. DELETE can be
dangerous, but it's also extremely convenient.
-Dan
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
http://mojavelinux.com
http://mojavelinux.com/seaminaction
NOTE: While I make a strong effort to keep up with my email on a daily
basis, personal or other work matters can sometimes keep me away
from my email. If you contact me, but don't hear back for more than a
week,
it is very likely that I am excessively backlogged or the message was
caught in the spam filters. Please don't hesitate to resend a message if
you feel that it did not reach my attention.
------------------------------------------------------------------------
_______________________________________________
seam-dev mailing list
seam-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev
6:06 p.m.
On Wed, Mar 4, 2009 at 5:05 PM, Max Rydahl Andersen <max.andersen(a)redhat.com
wrote:
Convenient does not mean it should be default.
Anyway, for GA we will keep the "old" default since it was discovered too
late.
Then when we do have the ui for controlling the default I would just have a
few options but
let none be the default since it is the less risky one and you can set the
default option in persistence.xml
instead of going set it on every single entity.
It's clearly a programming/architecture style since we all are pushing our
own viewpoints. Thus, I think you should have an option in the UI for the
user to enter whatever default he/she wants. Perhaps check boxes would be
nice.
I don't really like the idea of setting the defaults in the XML as it
changes the behavior of the application and makes it non-portable (or harder
to connect the dots for someone looking at the annotations).
So can we agree to disagree and make it a choice for the developer?
-Dan
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
http://mojavelinux.com
http://mojavelinux.com/seaminaction
NOTE: While I make a strong effort to keep up with my email on a daily
basis, personal or other work matters can sometimes keep me away
from my email. If you contact me, but don't hear back for more than a week,
it is very likely that I am excessively backlogged or the message was
caught in the spam filters. Please don't hesitate to resend a message if
you feel that it did not reach my attention.
6:06 p.m.
So can we agree to disagree and make it a choice for the developer?
I should also mention that it varies from application to application. It
really depends on how you will be using Hibernate/JPA.
-Dan
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
http://mojavelinux.com
http://mojavelinux.com/seaminaction
NOTE: While I make a strong effort to keep up with my email on a daily
basis, personal or other work matters can sometimes keep me away
from my email. If you contact me, but don't hear back for more than a week,
it is very likely that I am excessively backlogged or the message was
caught in the spam filters. Please don't hesitate to resend a message if
you feel that it did not reach my attention.
7:18 p.m.
On 05-03-2009 00:06, Dan Allen wrote:
On Wed, Mar 4, 2009 at 5:05 PM, Max Rydahl Andersen
<max.andersen(a)redhat.com <mailto:max.andersen@redhat.com>> wrote:
Convenient does not mean it should be default.
Anyway, for GA we will keep the "old" default since it was
discovered too late.
Then when we do have the ui for controlling the default I would
just have a few options but
let none be the default since it is the less risky one and you can
set the default option in persistence.xml
instead of going set it on every single entity.
It's clearly a programming/architecture style since we all are pushing
our own viewpoints. Thus, I think you should have an option in the UI
for the user to enter whatever default he/she wants. Perhaps check
boxes would be nice.
I don't really like the idea of setting the defaults in the XML as it
changes the behavior of the application and makes it non-portable (or
harder to connect the dots for someone looking at the annotations).
So can we agree to disagree and make it a choice for the developer?
I wrote that
above didn't I ? :) ALL is kept for now, a choice will be
added going forward.
btw. no single app in this world will use the same cascade on all
assocations hence setting i.e. ALL is
encouraging a very bad practice ... but for now I can't change it since
the alternative is just as bad because
of backwards compatability.
/max
-Dan
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
http://mojavelinux.com
http://mojavelinux.com/seaminaction
NOTE: While I make a strong effort to keep up with my email on a daily
basis, personal or other work matters can sometimes keep me away
from my email. If you contact me, but don't hear back for more than a
week,
it is very likely that I am excessively backlogged or the message was
caught in the spam filters. Please don't hesitate to resend a message if
you feel that it did not reach my attention.
7:34 p.m.
On Wed, Mar 4, 2009 at 7:18 PM, Max Rydahl Andersen <max.andersen(a)redhat.com
wrote:
> On 05-03-2009 00:06, Dan Allen wrote:
>
> On Wed, Mar 4, 2009 at 5:05 PM, Max Rydahl Andersen <
> max.andersen(a)redhat.com wrote:
>
>> Convenient does not mean it should be default.
>>
>> Anyway, for GA we will keep the "old" default since it was discovered
too
>> late.
>>
>> Then when we do have the ui for controlling the default I would just have
>> a few options but
>> let none be the default since it is the less risky one and you can set the
>> default option in persistence.xml
>> instead of going set it on every single entity.
>>
>
> It's clearly a programming/architecture style since we all are pushing our
> own viewpoints. Thus, I think you should have an option in the UI for the
> user to enter whatever default he/she wants. Perhaps check boxes would be
> nice.
>
> I don't really like the idea of setting the defaults in the XML as it
> changes the behavior of the application and makes it non-portable (or harder
> to connect the dots for someone looking at the annotations).
>
> So can we agree to disagree and make it a choice for the developer?
>
> I wrote that above didn't I ? :) ALL is kept for now, a choice will be
> added going forward.
>
> btw. no single app in this world will use the same cascade on all
> assocations hence setting i.e. ALL is
> encouraging a very bad practice ... but for now I can't change it since the
> alternative is just as bad because
> of backwards compatability.
>
Yep, I'll raise my glass to that.
-Dan
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
http://mojavelinux.com
http://mojavelinux.com/seaminaction
NOTE: While I make a strong effort to keep up with my email on a daily
basis, personal or other work matters can sometimes keep me away
from my email. If you contact me, but don't hear back for more than a week,
it is very likely that I am excessively backlogged or the message was
caught in the spam filters. Please don't hesitate to resend a message if
you feel that it did not reach my attention.
5531
days inactive
5535
days old
13 comments
5 participants
participants (5)
-
Dan Allen -
Daniel Hinojosa -
Emmanuel Bernard -
Max Rydahl Andersen -
Max Rydahl Andersen