Re: [Hibernate] Flush behavior

On Nov 21, 2005, at 2:03 AM, Gavin King wrote: Huh? http://opensource.atlassian.com/projects/hibernate/browse/HHH-1181 s.persist(o) is only transitive to anything reachable at call time. em.persist(o) is transitive at flush time. ---

Re: [Hibernate] Criterias OUTER JOIN when using Alias - Subquery

baliuka juozas wrote: All feature requests are very low priority after roadmap for the new release is approved, it is better to discuss new features before to start development on the new branch, it helps to plan releases. It is possible to vote it on jira too, it must be a good usefulness and

[Hibernate] How about mapping processing related properties

So far we've avoided properties involving mapping processing. Max wants to introduce a naming strategy property. There are several issues: 1 - you can set properties before / after / in between properties mapping => this is already the case for setNamingStrategy() 2 - who is going to win between

RE: [Hibernate] How about mapping processing related properties

I am not keen on this, because naming strategy is not "configuration". -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Emmanuel Bernard Sent: Monday, November 21, 2005 4:38 AM To: Hibernate development Subject: [Hibernate] How about mapping processing rela

RE: [Hibernate] Flush behavior

You are quite wrong. The persist() is applied and cascades at flush time. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christian Bauer Sent: Monday, November 21, 2005 1:46 AM To: Hibernate development Subject: Re: [Hibernate] Flush behavior On Nov 21

RE: [Hibernate] Flush behavior

Oh, you mean in plain Hibernate, not in HEM. This is again correct. You must enable cascade save-update, as in all versions of Hibernate. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gavin King Sent: Monday, November 21, 2005 5:07 AM To: Christian Baue

Re: [Hibernate] Flush behavior

On Nov 21, 2005, at 2:14 PM, Gavin King wrote: Oh, you mean in plain Hibernate, not in HEM. This is again correct. You must enable cascade save-update, as in all versions of Hibernate. Why? --- This SF.Net email is sponsored by the JBoss

Re: [Hibernate] Flush behavior

On Nov 21, 2005, at 2:46 PM, Christian Bauer wrote: Why? Ok, so I'm trying to come up with a paragraph that explains this for the documentation: Note that if you use cascade="persist", Hibernate will only cascade the persistent state to associated entities reachable at call time. If m

RE: [Hibernate] Flush behavior

>> This is again correct. You must enable cascade save-update, as in all >> versions of Hibernate. > Why? Because no other behavior would be well-defined. --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register fo

[Hibernate] query statistics

In relation to http://opensource2.atlassian.com/projects/hibernate/browse/HHH-73 (Statistics for HQL queries use pre-processed query string): The original issue behind this case is now easy to fix because of the introduction of query plans. The query plans know about the query strings before any

RE: [Hibernate] Flush behavior

I don't understand what is so difficult to understand here. Persist() is no different to delete(), merge() or evict() in this respect. You have to explain things in terms of what operation is applied at flush time. In the case of Hibernate it is the save/update operation. In the case of EJB3 it i

RE: [Hibernate] query statistics

Could the query plan cache both expanded and non-expanded SQL? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steve Ebersole Sent: Monday, November 21, 2005 6:49 AM To: Hibernate devel Subject: [Hibernate] query statistics In relation to http://opensourc

RE: [Hibernate] query statistics

I guess we could make it so. This issue is that currently it does not know the non-expanded query. -Original Message- From: Gavin King Sent: Monday, November 21, 2005 8:51 AM To: Steve Ebersole; Hibernate devel Subject: RE: [Hibernate] query statistics Could the query plan cache both ex

RE: [Hibernate] query statistics

Right. The only downside would be increased mem usage, I suppose. -Original Message- From: Steve Ebersole Sent: Monday, November 21, 2005 6:54 AM To: Gavin King; 'Hibernate devel' Subject: RE: [Hibernate] query statistics I guess we could make it so. This issue is that currently it doe

Re: [Hibernate] How about mapping processing related properties

On Mon, 21 Nov 2005 14:05:33 +0100, Gavin King <[EMAIL PROTECTED]> wrote: I am not keen on this, because naming strategy is not "configuration". Why is it not configuration ? /max -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Emmanuel Bernard S

Re: [Hibernate] query statistics

On Mon, 21 Nov 2005 15:55:22 +0100, Gavin King <[EMAIL PROTECTED]> wrote: Right. The only downside would be increased mem usage, I suppose. Done right it would only be in the cases of where its actually needed and even in that case it would only be *one* extra original query that you keep

[Hibernate] Fwd: [Hibernate-issues] [Hibernate-JIRA] Resolved: (EJB-35) Support custom NamingStrategy as property.

I fail to understand why its ok to add naming_strategy to ejb3 configuration and not hibernate configuration? /max --- Forwarded message --- From: "Emmanuel Bernard (JIRA)" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Cc: Subject: [Hibernate-issues] [Hibernate-JIRA] Resolved: (EJB-3