[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-35) Support
custom NamingStrategy as property.
Date: Mon, 21 Nov 2005 21:41:55 +0100
[ http://opensource.atlassian.com/projects/hibernate/browse/EJB-35?page=all
]
Emmanuel Bernard resolved EJB-35:
-
Assign To: Emmanuel Bernard
Resolution: Fixed
Support custom NamingStrategy as property.
--
Key: EJB-35
URL:
http://opensource.atlassian.com/projects/hibernate/browse/EJB-35
Project: Hibernate Entity Manager
Type: Improvement
Components: EntityManager
Versions: 3.1beta1
Environment: 3.1alpha1
EJB3 public draft
Reporter: Christian Stein
Assignee: Emmanuel Bernard
Fix For: 3.1beta5
Original Estimate: 1 hour
Remaining: 1 hour
As stated here http://forum.hibernate.org/viewtopic.php?t=944931 , I'd
like to set a custom NamingStrategy implementation in "persistenc.xml"s
properties.
At the moment, you can only set such a custom implementation
programmatically when creating a custom Configuration object. As this
object is hidden by the EJB persistence API, it should be possible to
specify the implementation class name via a property.
Mhhh... maybe the improvement should be issued against
"org.hibernate.cfg.Configuration" which needs a method like:
/**
* Set a custom naming strategy
*
* @param name the class name of NamingStrategy to set
*/
public Configuration setNamingStrategy(String name) {
this.namingStrategy = Class.forName(name);
return this;
}
Maybe, this is the wrong place. :)
Cheers,
Christian
--
--
Max Rydahl Andersen
callto://max.rydahl.andersen
Hibernate
[EMAIL PROTECTED]
http://hibernate.org
JBoss Inc
[EMAIL PROTECTED]
---
This SF.Net email is sponsored by the JBoss Inc. Get Certified Today
Register for a JBoss Training Course. Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
___
hibernate-devel mailing list
hibernate-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hibernate-devel
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 around. Not any big increase - i think. /max -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 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 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://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 processing has occurred. So simply moving the stats API calls into the query plans will get around the mentioned issue. However, I brought up another point there regarding parameter-list expansion. Currently, this is done within the QueryImpls, such that the expansion has occurred before the query string even gets to query plans/translators. This leads to scenarios where the HQL: "from Animal where description in (:descriptionList)" Results in different statistics being tracked based on the number of parameters actually contained in the bound descriptionList. To me, for the same arguments as the original issue, it is non-intuitive to issue "from Animal where description in (:descriptionList)" as an HQL query, but to see things like "from Animal where description in (:descriptionList0_, :descriptionList1_)" in the statistics. The flip side of this is that "correcting" this behavior means delaying generation of the actual SQL until the QueryParameters are actually known. AFAICT, this really only effects the tools since the tools want to display the translated SQL within the console; however, the SQL may not be fully resolvable at that point in time if we start delaying the resolution of the SQL till execution. So I wanted to open this up for discussion. What makes the most sense here? --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_idv28&alloc_id845&op=ick ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_idv28&alloc_id845&op=click ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel -- -- Max Rydahl Andersen callto://max.rydahl.andersen Hibernate [EMAIL PROTECTED] http://hibernate.org JBoss Inc [EMAIL PROTECTED] --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel
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
Sent: Monday, November 21, 2005 4:38 AM
To: Hibernate development
Subject: [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 a property and it's object
representation (ie setNS() vs setProperty("naming_strategy") vs
hibernate.cfg.xml)
3 - has to be a no-arg constructor
Are we ready to open Hibernate core to such subtle configuration errors,
or should I keep this in HEM?
---
This SF.Net email is sponsored by the JBoss Inc. Get Certified Today
Register for a JBoss Training Course. Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
___
hibernate-devel mailing list
hibernate-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hibernate-devel
---
This SF.Net email is sponsored by the JBoss Inc. Get Certified Today
Register for a JBoss Training Course. Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_idv28&alloc_id845&op=click
___
hibernate-devel mailing list
hibernate-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hibernate-devel
--
--
Max Rydahl Andersen
callto://max.rydahl.andersen
Hibernate
[EMAIL PROTECTED]
http://hibernate.org
JBoss Inc
[EMAIL PROTECTED]
---
This SF.Net email is sponsored by the JBoss Inc. Get Certified Today
Register for a JBoss Training Course. Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
___
hibernate-devel mailing list
hibernate-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hibernate-devel
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 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 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://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 processing has occurred. So simply moving the stats API calls into the query plans will get around the mentioned issue. However, I brought up another point there regarding parameter-list expansion. Currently, this is done within the QueryImpls, such that the expansion has occurred before the query string even gets to query plans/translators. This leads to scenarios where the HQL: "from Animal where description in (:descriptionList)" Results in different statistics being tracked based on the number of parameters actually contained in the bound descriptionList. To me, for the same arguments as the original issue, it is non-intuitive to issue "from Animal where description in (:descriptionList)" as an HQL query, but to see things like "from Animal where description in (:descriptionList0_, :descriptionList1_)" in the statistics. The flip side of this is that "correcting" this behavior means delaying generation of the actual SQL until the QueryParameters are actually known. AFAICT, this really only effects the tools since the tools want to display the translated SQL within the console; however, the SQL may not be fully resolvable at that point in time if we start delaying the resolution of the SQL till execution. So I wanted to open this up for discussion. What makes the most sense here? --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_idv28&alloc_id845&op=ick ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_idv28&alloc_id845&op=click ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel
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 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://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 processing has occurred. So simply moving the stats API calls into the query plans will get around the mentioned issue. However, I brought up another point there regarding parameter-list expansion. Currently, this is done within the QueryImpls, such that the expansion has occurred before the query string even gets to query plans/translators. This leads to scenarios where the HQL: "from Animal where description in (:descriptionList)" Results in different statistics being tracked based on the number of parameters actually contained in the bound descriptionList. To me, for the same arguments as the original issue, it is non-intuitive to issue "from Animal where description in (:descriptionList)" as an HQL query, but to see things like "from Animal where description in (:descriptionList0_, :descriptionList1_)" in the statistics. The flip side of this is that "correcting" this behavior means delaying generation of the actual SQL until the QueryParameters are actually known. AFAICT, this really only effects the tools since the tools want to display the translated SQL within the console; however, the SQL may not be fully resolvable at that point in time if we start delaying the resolution of the SQL till execution. So I wanted to open this up for discussion. What makes the most sense here? --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_idv28&alloc_id845&op=ick ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_idv28&alloc_id845&op=click ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel
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://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 processing has occurred. So simply moving the stats API calls into the query plans will get around the mentioned issue. However, I brought up another point there regarding parameter-list expansion. Currently, this is done within the QueryImpls, such that the expansion has occurred before the query string even gets to query plans/translators. This leads to scenarios where the HQL: "from Animal where description in (:descriptionList)" Results in different statistics being tracked based on the number of parameters actually contained in the bound descriptionList. To me, for the same arguments as the original issue, it is non-intuitive to issue "from Animal where description in (:descriptionList)" as an HQL query, but to see things like "from Animal where description in (:descriptionList0_, :descriptionList1_)" in the statistics. The flip side of this is that "correcting" this behavior means delaying generation of the actual SQL until the QueryParameters are actually known. AFAICT, this really only effects the tools since the tools want to display the translated SQL within the console; however, the SQL may not be fully resolvable at that point in time if we start delaying the resolution of the SQL till execution. So I wanted to open this up for discussion. What makes the most sense here? --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_idv28&alloc_id845&op=ick ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_idv28&alloc_id845&op=click ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel
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 is the persist operation. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christian Bauer Sent: Monday, November 21, 2005 6:18 AM To: Hibernate development Subject: 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 more transient entities are associated with already persistent instances, they will not become persistent, unless you also use the save-update option, cascade="persist, save-update". Hibernate then cascades the persistent state at flush time to all reachable entity instances, if save-update is enabled for an association. Correct? --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_idv28&alloc_id845&op=click ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel
[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 processing has occurred. So simply moving the stats API calls into the query plans will get around the mentioned issue. However, I brought up another point there regarding parameter-list expansion. Currently, this is done within the QueryImpls, such that the expansion has occurred before the query string even gets to query plans/translators. This leads to scenarios where the HQL: "from Animal where description in (:descriptionList)" Results in different statistics being tracked based on the number of parameters actually contained in the bound descriptionList. To me, for the same arguments as the original issue, it is non-intuitive to issue "from Animal where description in (:descriptionList)" as an HQL query, but to see things like "from Animal where description in (:descriptionList0_, :descriptionList1_)" in the statistics. The flip side of this is that "correcting" this behavior means delaying generation of the actual SQL until the QueryParameters are actually known. AFAICT, this really only effects the tools since the tools want to display the translated SQL within the console; however, the SQL may not be fully resolvable at that point in time if we start delaying the resolution of the SQL till execution. So I wanted to open this up for discussion. What makes the most sense here? --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_idv28&alloc_id845&op=click ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel
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 for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_idv28&alloc_id845&op=click ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel
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 more transient entities are associated with already persistent instances, they will not become persistent, unless you also use the save-update option, cascade="persist, save-update". Hibernate then cascades the persistent state at flush time to all reachable entity instances, if save-update is enabled for an association. Correct? --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel
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 Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel
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 Bauer; Hibernate development Subject: 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, 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. --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_idv28&alloc_id845&op=ick ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_idv28&alloc_id845&op=click ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel
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, 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. --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_idv28&alloc_id845&op=click ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel
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 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 a property and it's object
representation (ie setNS() vs setProperty("naming_strategy") vs
hibernate.cfg.xml)
3 - has to be a no-arg constructor
Are we ready to open Hibernate core to such subtle configuration errors,
or should I keep this in HEM?
---
This SF.Net email is sponsored by the JBoss Inc. Get Certified Today
Register for a JBoss Training Course. Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
___
hibernate-devel mailing list
hibernate-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hibernate-devel
---
This SF.Net email is sponsored by the JBoss Inc. Get Certified Today
Register for a JBoss Training Course. Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_idv28&alloc_id845&op=click
___
hibernate-devel mailing list
hibernate-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hibernate-devel
[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 a property and it's object
representation (ie setNS() vs setProperty("naming_strategy") vs
hibernate.cfg.xml)
3 - has to be a no-arg constructor
Are we ready to open Hibernate core to such subtle configuration errors,
or should I keep this in HEM?
---
This SF.Net email is sponsored by the JBoss Inc. Get Certified Today
Register for a JBoss Training Course. Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
___
hibernate-devel mailing list
hibernate-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hibernate-devel
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 priority indicator. But it must be better to delay issue than to close it too ( this information can be useful the next release, jira must help to maintain it ). My main concern is because people close feature requests instead of delaying them, we lose all track of the requested change. Then JIRA voting and other features are disabled too, so we can't really know if a issue is popular or not. And last but not least, the rejections are based on personal motivations (or just lack of interest) instead of valid technical reasons (which should be commented in JIRA for other people to see and to avoid dupes). So important features get ignored very easily. The mailing list is usually a worse option, since people tend to ignore "naggers" just because they ask for a reason of a rejection. I'll probably patch myself the source, but I'd rather see it in the main codebase for other people to benefit from it (and to get some feedback). -- Ing. Leonardo Quijano Vincenzi Director Técnico DTQ Software --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel
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. --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel
