Menu
▾
▴
hibernate-issues — Hibernate JIRA Notifications
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(32) |
Jun
(175) |
Jul
(209) |
Aug
(302) |
Sep
(287) |
Oct
(339) |
Nov
(314) |
Dec
(329) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(479) |
Feb
(389) |
Mar
(599) |
Apr
(307) |
May
(390) |
Jun
(300) |
Jul
(410) |
Aug
(458) |
Sep
(299) |
Oct
(315) |
Nov
(363) |
Dec
(529) |
| 2005 |
Jan
(568) |
Feb
(434) |
Mar
(1004) |
Apr
(823) |
May
(767) |
Jun
(763) |
Jul
(854) |
Aug
(862) |
Sep
(560) |
Oct
(853) |
Nov
(763) |
Dec
(731) |
| 2006 |
Jan
(776) |
Feb
(608) |
Mar
(657) |
Apr
(424) |
May
(559) |
Jun
(440) |
Jul
(448) |
Aug
(58) |
Sep
|
Oct
(17) |
Nov
(16) |
Dec
(8) |
| 2007 |
Jan
(1) |
Feb
(8) |
Mar
(2) |
Apr
(5) |
May
(3) |
Jun
(3) |
Jul
(3) |
Aug
(16) |
Sep
(10) |
Oct
(4) |
Nov
(4) |
Dec
(4) |
| 2008 |
Jan
(8) |
Feb
(1) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
|
From: <leg...@at...> - 2003-08-08 23:52:14
|
The following comment has been added to this issue:
Author: John Kristian
Created: Fri, 8 Aug 2003 6:51 PM
Body:
I first reported this issue in <http://sourceforge.net/forum/forum.php?thread_id=911047&forum_id=128638>.
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-241
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-241
Summary: cached collection depends on closed Session
Type: Bug
Status: Unassigned
Priority: Major
Project: Hibernate2
Components:
core
Versions:
2.0.1
Assignee:
Reporter: John Kristian
Created: Fri, 8 Aug 2003 6:48 PM
Updated: Fri, 8 Aug 2003 6:48 PM
Environment: Windows XP, JBoss 3, Microsoft SQL Server
Description:
There's a problem with a collection in the JCS cache that contains entities whose composite-id contains a reference to an entity that contains a lazy collection. An exception 'Failed to lazily initialize a collection - no Session' is thrown when attempting to initialize a lazy collection member of an entity referred to by the composite-id of an entity contained in a collection from the JCS cache, if the cached collection was loaded (and cached) by a Session that is now closed.
An exception should not be thrown, in this case. The lazy collection should be initialized using the Session that found the cached collection.
It appears (although I'm not entirely certain) that composite-ids from the cached collection contain references to entities that were loaded by a previous Session (that missed the JCS cache) which is now closed. This seems erroneous, to me; I think such a composite-id should contain references to entities in the current Session (that hit the JCS cache).
To work around this problem, I intend to make the setId method of my entities check the references (if any) in the new id and replace them, if necessary, with references to objects with the same id but in the same Session as the containing entity. Critique and better ideas are welcome <mailto:jkr...@do...>.
I have a tolerably small test case, which I'll attach to this issue if I can figure out how. (I'm not familiar with JIRA.)
---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <leg...@at...> - 2003-08-08 23:50:10
|
Message: A new issue has been created in JIRA. --------------------------------------------------------------------- View the issue: http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-241 Here is an overview of the issue: --------------------------------------------------------------------- Key: HB-241 Summary: cached collection depends on closed Session Type: Bug Status: Unassigned Priority: Major Project: Hibernate2 Components: core Versions: 2.0.1 Assignee: Reporter: John Kristian Created: Fri, 8 Aug 2003 6:48 PM Updated: Fri, 8 Aug 2003 6:48 PM Environment: Windows XP, JBoss 3, Microsoft SQL Server Description: There's a problem with a collection in the JCS cache that contains entities whose composite-id contains a reference to an entity that contains a lazy collection. An exception 'Failed to lazily initialize a collection - no Session' is thrown when attempting to initialize a lazy collection member of an entity referred to by the composite-id of an entity contained in a collection from the JCS cache, if the cached collection was loaded (and cached) by a Session that is now closed. An exception should not be thrown, in this case. The lazy collection should be initialized using the Session that found the cached collection. It appears (although I'm not entirely certain) that composite-ids from the cached collection contain references to entities that were loaded by a previous Session (that missed the JCS cache) which is now closed. This seems erroneous, to me; I think such a composite-id should contain references to entities in the current Session (that hit the JCS cache). To work around this problem, I intend to make the setId method of my entities check the references (if any) in the new id and replace them, if necessary, with references to objects with the same id but in the same Session as the containing entity. Critique and better ideas are welcome <mailto:jkr...@do...>. I have a tolerably small test case, which I'll attach to this issue if I can figure out how. (I'm not familiar with JIRA.) --------------------------------------------------------------------- JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira |
|
From: <leg...@at...> - 2003-08-08 22:10:14
|
The following comment has been added to this issue:
Author: Christian Bauer
Created: Fri, 8 Aug 2003 5:09 PM
Body:
IntelliJ's code inspector found hundreds of problems with JavaDoc: missing parameters, returns, wrong parameter names and so on.
The error messages in the build are just info, they indicate that a period was detected which was propably not the end of the first sentence, as in:
* Attempt to obtain an upgrade lock, using an Oracle-style
* <tt>select ... for update nowait</tt>. The semantics of
The first sentence is used in the overview pages.
I'll rework all of the comments. This may conflict with outstanding commits, but I guess today is a good time. I'll only work on the 2.1 branch and ping again when I'm finished to coordinate the commit.
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-239
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-239
Summary: javadoc build spits >200 warnings
Type: Bug
Status: Assigned
Priority: Trivial
Project: Hibernate2
Components:
core
Versions:
2.0.2
Assignee: Christian Bauer
Reporter: Gavin King
Created: Thu, 7 Aug 2003 7:43 AM
Updated: Thu, 7 Aug 2003 7:43 AM
Environment: Ant build
Description:
The javadoc build currently spits many warnings, all the same.
---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <leg...@at...> - 2003-08-08 16:54:14
|
Message:
The following issue has been closed.
Resolver: Gavin King
Date: Fri, 8 Aug 2003 11:53 AM
closing this ... I'm assuming there is no problem....
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-236
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-236
Summary: Deep subclassing fails configuration
Type: Bug
Status: Closed
Priority: Major
Resolution: REJECTED
Project: Hibernate2
Components:
core
Versions:
2.0.1
Assignee:
Reporter: Brian Topping
Created: Wed, 6 Aug 2003 7:09 AM
Updated: Fri, 8 Aug 2003 11:53 AM
Environment: JDK 1.4.1
Description:
Persistence configuration fails when the inheritance depth is greater than two. I was generating a patch, but couldn't get into sf.net to get base CVS for diffs.
It looks to me like ReflectHelper.getGetterOrNull() simply needs a loop to keep checking subclasses all the way up the chain instead of stopping with just one. At least for standard subclass behavior where there is a discriminator, there shouldn't be a problem with arbitrarily deep inheritance. But like I said, I can't get sources so I try it and send a diff. I guess it's the middle of the day in the western hemisphere now, so I'll try tomorrow.
If I get something before you fix it, I'll post it here.
---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <leg...@at...> - 2003-08-08 16:51:14
|
Message:
The following issue has been resolved as FIXED.
Resolver: Max Rydahl Andersen
Date: Fri, 8 Aug 2003 11:50 AM
A first version of this has been commited to the cvs branch v21
(does not support composite properties/ids yet - but it handles all the other stuff ;)
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-18
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-18
Summary: Integrate support for SQL queries
Type: New Feature
Status: Resolved
Priority: Major
Resolution: FIXED
Project: Hibernate2
Fix Fors:
2.1 beta 1
Assignee: Max Rydahl Andersen
Reporter: Max Rydahl Andersen
Created: Sat, 3 May 2003 10:08 AM
Updated: Fri, 8 Aug 2003 11:50 AM
Description:
Integrate support for SQL queries
To execute SQL in Hibernate one aquires a connection as normal
or via the session object.
This can really only be used to
fetch scalar values.
A real nice feature would be to be able to
provide SQL directly as an alternative to HQL. The SQL should
ofcourse return the named columns and data types that Hibernate
expects to be able to instantiate objects from the resultset.
(original: http://sourceforge.net/tracker/index.php?func=detail&aid=622605&group_id=40712&atid=428711=
---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <leg...@at...> - 2003-08-08 13:15:21
|
The following comment has been added to this issue:
Author: Gavin King
Created: Fri, 8 Aug 2003 8:14 AM
Body:
Max, why don't you just comit this? The diff doesn't look like it worked too well anyway.
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-18
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-18
Summary: Integrate support for SQL queries
Type: New Feature
Status: In Progress
Priority: Major
Project: Hibernate2
Assignee: Max Rydahl Andersen
Reporter: Max Rydahl Andersen
Created: Sat, 3 May 2003 10:08 AM
Updated: Fri, 8 Aug 2003 5:49 AM
Description:
Integrate support for SQL queries
To execute SQL in Hibernate one aquires a connection as normal
or via the session object.
This can really only be used to
fetch scalar values.
A real nice feature would be to be able to
provide SQL directly as an alternative to HQL. The SQL should
ofcourse return the named columns and data types that Hibernate
expects to be able to instantiate objects from the resultset.
(original: http://sourceforge.net/tracker/index.php?func=detail&aid=622605&group_id=40712&atid=428711=
---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <leg...@at...> - 2003-08-08 10:52:14
|
The following comment has been added to this issue:
Author: Max Rydahl Andersen
Created: Fri, 8 Aug 2003 5:50 AM
Body:
I've completed the implementaiton of SQLLoader - except for the composite properties part. But this is easily added, i just probably can't get it done before the weekend is over ,(
but this code can handle pretty much else ;)
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-18
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-18
Summary: Integrate support for SQL queries
Type: New Feature
Status: In Progress
Priority: Major
Project: Hibernate2
Assignee: Max Rydahl Andersen
Reporter: Max Rydahl Andersen
Created: Sat, 3 May 2003 10:08 AM
Updated: Fri, 8 Aug 2003 5:49 AM
Description:
Integrate support for SQL queries
To execute SQL in Hibernate one aquires a connection as normal
or via the session object.
This can really only be used to
fetch scalar values.
A real nice feature would be to be able to
provide SQL directly as an alternative to HQL. The SQL should
ofcourse return the named columns and data types that Hibernate
expects to be able to instantiate objects from the resultset.
(original: http://sourceforge.net/tracker/index.php?func=detail&aid=622605&group_id=40712&atid=428711=
---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <leg...@at...> - 2003-08-08 10:50:17
|
The following issue has been updated:
Updater: Max Rydahl Andersen (mailto:xa...@xa...)
Date: Fri, 8 Aug 2003 5:49 AM
Comment:
every thing you wish for EXCEPT composite properties.
Changes:
Attachment changed to sqlloader.patch
---------------------------------------------------------------------
For a full history of the issue, see:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-18&page=history
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-18
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-18
Summary: Integrate support for SQL queries
Type: New Feature
Status: In Progress
Priority: Major
Project: Hibernate2
Assignee: Max Rydahl Andersen
Reporter: Max Rydahl Andersen
Created: Sat, 3 May 2003 10:08 AM
Updated: Fri, 8 Aug 2003 5:49 AM
Description:
Integrate support for SQL queries
To execute SQL in Hibernate one aquires a connection as normal
or via the session object.
This can really only be used to
fetch scalar values.
A real nice feature would be to be able to
provide SQL directly as an alternative to HQL. The SQL should
ofcourse return the named columns and data types that Hibernate
expects to be able to instantiate objects from the resultset.
(original: http://sourceforge.net/tracker/index.php?func=detail&aid=622605&group_id=40712&atid=428711=
---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <leg...@at...> - 2003-08-08 08:24:14
|
Message:
The following issue has been closed.
Resolver: Gavin King
Date: Fri, 8 Aug 2003 3:23 AM
I fixed this a while ago.
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-84
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-84
Summary: Add debug/info log message to net.sf.hibernate.cfg.Configuration
Type: Improvement
Status: Closed
Priority: Minor
Resolution: FIXED
Project: Hibernate2
Fix Fors:
2.0.2
Versions:
2.0rc2
Assignee:
Reporter: Mike Panzitta
Created: Sat, 17 May 2003 3:52 PM
Updated: Fri, 8 Aug 2003 3:23 AM
Description:
Please add a log.info or similar message in the secondPassCompile() method to improve isolating problems with .hbm.cfg files. For example:
------------excerpt from Configuration.java ----------
private void secondPassCompile() throws MappingException {
...
iter = getTableMappings();
while ( iter.hasNext() ) {
Table table = (Table) iter.next();
log.info("Running second pass on table: " + table.getName());
Iterator subIter = table.getForeignKeyIterator();
while ( subIter.hasNext() ) {
ForeignKey fk = (ForeignKey) subIter.next();
log.info("-- Resolving foreign key: " + fk.getName());
...
---------------------------
With a lot of classes, it is difficult to figure out in which .hbm.cfg file a problem is occurring.
Thanks in advance,
-Mike
---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <leg...@at...> - 2003-08-08 06:14:19
|
Message:
The following issue has been closed.
Resolver: Gavin King
Date: Fri, 8 Aug 2003 1:13 AM
I implemented something similar to this, that does not require a dependency upon crossdb.
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-43
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-43
Summary: Auto db build
Type: Patch
Status: Closed
Priority: Major
Resolution: FIXED
Project: Hibernate2
Assignee: Gavin King
Reporter: Max Rydahl Andersen
Created: Sat, 3 May 2003 10:27 AM
Updated: Fri, 8 Aug 2003 1:13 AM
Description:
Auto db build
small change in Configuation and new class.
Turned on by the following property:
hibernate.autobuilddb true
Small change required in Configuration: replace
buildSessionFactory with this one:
public SessionFactory buildSessionFactory() throws
HibernateException {
secondPassCompile();
Environment.verifyProperties
(properties);
Properties copy = new Properties
();
copy.putAll(properties);
SessionFactoryImpl sessImpl =
new SessionFactoryImpl(this, copy, interceptor);
// build db if autobuild set
String autobuilddb = (String) properties.get
("hibernate.autobuilddb");
if(autobuilddb != null &&
autobuilddb.equalsIgnoreCase("true")){
DbBuilder.autoBuild(this, sessImpl);
}
return sessImpl;
}
http://sourceforge.net/tracker/index.php?func=detail&aid=709940&group_id=40712&atid=428710
---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <leg...@at...> - 2003-08-08 00:49:14
|
The following comment has been added to this issue:
Author: Max Rydahl Andersen
Created: Thu, 7 Aug 2003 7:48 PM
Body:
DONE * multiple object results
that was a tricky one ;)
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-18
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-18
Summary: Integrate support for SQL queries
Type: New Feature
Status: In Progress
Priority: Major
Project: Hibernate2
Assignee: Max Rydahl Andersen
Reporter: Max Rydahl Andersen
Created: Sat, 3 May 2003 10:08 AM
Updated: Wed, 6 Aug 2003 6:10 AM
Description:
Integrate support for SQL queries
To execute SQL in Hibernate one aquires a connection as normal
or via the session object.
This can really only be used to
fetch scalar values.
A real nice feature would be to be able to
provide SQL directly as an alternative to HQL. The SQL should
ofcourse return the named columns and data types that Hibernate
expects to be able to instantiate objects from the resultset.
(original: http://sourceforge.net/tracker/index.php?func=detail&aid=622605&group_id=40712&atid=428711=
---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <leg...@at...> - 2003-08-08 00:08:16
|
Message: The following issue has been re-assigned. Assignee: Gavin King (mailto:ga...@in...) --------------------------------------------------------------------- View the issue: http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-232 Here is an overview of the issue: --------------------------------------------------------------------- Key: HB-232 Summary: Custom types cannot be uses for ids with indentity and sequence generators Type: Improvement Status: Assigned Priority: Minor Project: Hibernate2 Components: core Versions: 2.0rc2 Assignee: Gavin King Reporter: James Lewis Created: Tue, 5 Aug 2003 9:37 AM Updated: Thu, 7 Aug 2003 7:07 PM Environment: Any environment. MySql DB Description: All of my persistent objects have a custom primary key object. For instance, my Part object has a PartID as the key. This allows me to perform compile time type checking in my service layer. I was ably to create a UserType that converted the coulmn type of integer to PartID. No problem, it worked great. However, the IdentityGeneratorFactory throw an exception because my custom types return PartID.class as the return type. The IdentityGeneratorFactory's 'get' method only takes classes that are of type Integer.class, Long.class, and Short.class. The API should be changed so that the get method returns a Serializable instead of a Number, and takes a Type instead of a class. This would allow the IdentityGeneratorFactory to return the custom class type. What are your thoughts. James --------------------------------------------------------------------- JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira |
|
From: <leg...@at...> - 2003-08-07 23:57:14
|
Message:
The following issue has been closed.
Resolver: Gavin King
Date: Thu, 7 Aug 2003 6:57 PM
Hibernate is currently LGPL. Even though we are considering a change to artistic license or some such, Hibernate will not be released under the BSD license.
Plus, we would much rather concentrate upon development than upon Apache project politics.
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-237
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-237
Summary: Hibernate is not an Apache Jakarta project
Type: Improvement
Status: Closed
Priority: Major
Resolution: REJECTED
Project: Hibernate2
Assignee:
Reporter: Maik Schreiber
Created: Wed, 6 Aug 2003 7:12 AM
Updated: Thu, 7 Aug 2003 6:57 PM
Description:
Hibernate is not an Apache Jakarta project, although IMHO it really should be.
---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <leg...@at...> - 2003-08-07 20:37:14
|
The following comment has been added to this issue:
Author: Max Rydahl Andersen
Created: Thu, 7 Aug 2003 3:36 PM
Body:
DONE * SQLQuery interface replaced by Query
DONE * {person.class} for discriminator column
(not attached yet...just to inform ya ;)
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-18
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-18
Summary: Integrate support for SQL queries
Type: New Feature
Status: In Progress
Priority: Major
Project: Hibernate2
Assignee: Max Rydahl Andersen
Reporter: Max Rydahl Andersen
Created: Sat, 3 May 2003 10:08 AM
Updated: Wed, 6 Aug 2003 6:10 AM
Description:
Integrate support for SQL queries
To execute SQL in Hibernate one aquires a connection as normal
or via the session object.
This can really only be used to
fetch scalar values.
A real nice feature would be to be able to
provide SQL directly as an alternative to HQL. The SQL should
ofcourse return the named columns and data types that Hibernate
expects to be able to instantiate objects from the resultset.
(original: http://sourceforge.net/tracker/index.php?func=detail&aid=622605&group_id=40712&atid=428711=
---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <leg...@at...> - 2003-08-07 18:50:14
|
The following comment has been added to this issue:
Author: Max Rydahl Andersen
Created: Thu, 7 Aug 2003 1:49 PM
Body:
"impedeance mismatch" in the SQL ;)
I got a question for ya' ;)
If I want to load all A.class's with my SQLQuery i also have to get ALL the columns for my potential subclasses properties (Hibernate expects that)
Currently this actually works:
session.createSQLQuery("select id as {a.id}, clazz as {a.class}, count_ as {a.count}, name as {a.name} from A", "a", A.class);
But note that {a.count} is actually referring to B.class property count, is this not misleading ?
Is it ok to refer to subclasses properties as what is happening in this case ?
Should we instead support class based property references ? so, the above would be:
session.createSQLQuery("select id as {A.id}, clazz as {A.class}, count_ as {B.count}, name as {A.name} from A", "myA", A.class);
Notice that A and B is now references to the mapped classes A and B.
Here i don't even need the "myA" alias name....
...or should we instead just keep the "old" syntax and then look at the alias name as an alias for the returnClass + their subclasses ? (this is what happens now ;)
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-18
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-18
Summary: Integrate support for SQL queries
Type: New Feature
Status: In Progress
Priority: Major
Project: Hibernate2
Assignee: Max Rydahl Andersen
Reporter: Max Rydahl Andersen
Created: Sat, 3 May 2003 10:08 AM
Updated: Wed, 6 Aug 2003 6:10 AM
Description:
Integrate support for SQL queries
To execute SQL in Hibernate one aquires a connection as normal
or via the session object.
This can really only be used to
fetch scalar values.
A real nice feature would be to be able to
provide SQL directly as an alternative to HQL. The SQL should
ofcourse return the named columns and data types that Hibernate
expects to be able to instantiate objects from the resultset.
(original: http://sourceforge.net/tracker/index.php?func=detail&aid=622605&group_id=40712&atid=428711=
---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <leg...@at...> - 2003-08-07 17:55:14
|
The following comment has been added to this issue:
Author: Gavin King
Created: Thu, 7 Aug 2003 12:54 PM
Body:
looking really good. I'd love to see:
* multiple object results
* SQLQuery interface replaced by Query
* {person.*} to insert persister.propertySelectFragment("person")
* support for named and positional parameters
* {person.class} for discriminator column
* {person.component.property} to support components
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-18
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-18
Summary: Integrate support for SQL queries
Type: New Feature
Status: In Progress
Priority: Major
Project: Hibernate2
Assignee: Max Rydahl Andersen
Reporter: Max Rydahl Andersen
Created: Sat, 3 May 2003 10:08 AM
Updated: Wed, 6 Aug 2003 6:10 AM
Description:
Integrate support for SQL queries
To execute SQL in Hibernate one aquires a connection as normal
or via the session object.
This can really only be used to
fetch scalar values.
A real nice feature would be to be able to
provide SQL directly as an alternative to HQL. The SQL should
ofcourse return the named columns and data types that Hibernate
expects to be able to instantiate objects from the resultset.
(original: http://sourceforge.net/tracker/index.php?func=detail&aid=622605&group_id=40712&atid=428711=
---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <leg...@at...> - 2003-08-07 16:23:41
|
Message:
The following issue has been closed.
Resolver: Gavin King
Date: Thu, 7 Aug 2003 11:02 AM
I've implemented this, finally.
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-36
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-36
Summary: clear() the session cache
Type: New Feature
Status: Closed
Priority: Major
Resolution: FIXED
Project: Hibernate2
Fix Fors:
2.1 beta 1
Assignee: Gavin King
Reporter: Max Rydahl Andersen
Created: Sat, 3 May 2003 10:21 AM
Updated: Thu, 7 Aug 2003 11:02 AM
Description:
clear() the session cache
Like evict, but clears the entire session at once.
Useful for batch processing, where a large cache can
result in out of memory exceptions.
The standard use case would be a transaction where you
are updating many objects, and want to flush/clear
periodically:
int counter = 0;
while (it.hasNext()) {
Foo foo = (Foo)it.next();
foo.setBar(42);
if ((counter++ % 10000) == 0) {
session.flush();
session.clear();
}
}
The current workaround is to flush and evict after each
update, but here you lose the benefits of batched updates:
while (it.hasNext()) {
Foo foo = (Foo)it.next();
foo.setBar(42);
session.flush();
session.evict(foo);
}
http://sourceforge.net/tracker/index.php?func=detail&aid=728730&group_id=40712&atid=428711
---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <leg...@at...> - 2003-08-07 15:57:14
|
Message:
The following issue has been closed.
Resolver: Gavin King
Date: Thu, 7 Aug 2003 10:56 AM
This was already fixed in CVS. IBM changed things behind our backs. The latest implementation supports both variations.
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-240
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-240
Summary: The net.sf.hibernate.transaction.WebSphereTransactionManagerLookup invokes a non-existant method on a JTSXA object
Type: Bug
Status: Closed
Priority: Major
Resolution: DUPLICATE
Project: Hibernate2
Versions:
2.0 final
Assignee:
Reporter: Tomasz Jankowski
Created: Thu, 7 Aug 2003 9:35 AM
Updated: Thu, 7 Aug 2003 10:56 AM
Environment: Experienced on a Win2k machine running WebSphere Enterprise Studio/WebSphere 5.0, the code involved does NOT seem to be platform dependent but IS appServer dependent
Description:
Specifying a JNDI DataSource in hibernate.cfg.cml when running on WebSphere 5.0 will produce errors related to the transaction.manager_lookup_class. The class to specify for this property is net.sf.hibernate.transaction.WebSphereTransactionManagerLookup according to the Hibernate documentation.
The bug is reproduced when the return statement is reached in the getTransactionManager(Properties) method of the lookup class. That statement tries to dynamically invoke a static method getTransactionManager() on the com.ibm.ejs.jts.jta.JTSXA class - the problem is that there's no such method. The fix is to call the correct method: instance().
Original code:
.
.
return (TransactionManager) clazz
.getMethod("getTransactionManager", null)
.invoke(null, null);
.
.
Suggested correction (tested by overloading the original):
.
.
return (TransactionManager)clazz.getDeclaredMethod("instance", null).invoke(null,null);
.
.
Thanks!
---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <leg...@at...> - 2003-08-07 14:36:20
|
Message: A new issue has been created in JIRA. --------------------------------------------------------------------- View the issue: http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-240 Here is an overview of the issue: --------------------------------------------------------------------- Key: HB-240 Summary: The net.sf.hibernate.transaction.WebSphereTransactionManagerLookup invokes a non-existant method on a JTSXA object Type: Bug Status: Unassigned Priority: Major Project: Hibernate2 Versions: 2.0 final Assignee: Reporter: Tomasz Jankowski Created: Thu, 7 Aug 2003 9:35 AM Updated: Thu, 7 Aug 2003 9:35 AM Environment: Experienced on a Win2k machine running WebSphere Enterprise Studio/WebSphere 5.0, the code involved does NOT seem to be platform dependent but IS appServer dependent Description: Specifying a JNDI DataSource in hibernate.cfg.cml when running on WebSphere 5.0 will produce errors related to the transaction.manager_lookup_class. The class to specify for this property is net.sf.hibernate.transaction.WebSphereTransactionManagerLookup according to the Hibernate documentation. The bug is reproduced when the return statement is reached in the getTransactionManager(Properties) method of the lookup class. That statement tries to dynamically invoke a static method getTransactionManager() on the com.ibm.ejs.jts.jta.JTSXA class - the problem is that there's no such method. The fix is to call the correct method: instance(). Original code: . . return (TransactionManager) clazz .getMethod("getTransactionManager", null) .invoke(null, null); . . Suggested correction (tested by overloading the original): . . return (TransactionManager)clazz.getDeclaredMethod("instance", null).invoke(null,null); . . Thanks! --------------------------------------------------------------------- JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira |
|
From: <leg...@at...> - 2003-08-07 12:44:18
|
Message: A new issue has been created in JIRA. --------------------------------------------------------------------- View the issue: http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-239 Here is an overview of the issue: --------------------------------------------------------------------- Key: HB-239 Summary: javadoc build spits >200 warnings Type: Bug Status: Assigned Priority: Trivial Project: Hibernate2 Components: core Versions: 2.0.2 Assignee: Christian Bauer Reporter: Gavin King Created: Thu, 7 Aug 2003 7:43 AM Updated: Thu, 7 Aug 2003 7:43 AM Environment: Ant build Description: The javadoc build currently spits many warnings, all the same. --------------------------------------------------------------------- JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira |
|
From: <leg...@at...> - 2003-08-06 22:56:17
|
Message:
The following issue has been reopened.
Reopener: Christian Bauer
Date: Wed, 6 Aug 2003 5:05 PM
OK, thanks for spotting this.
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-238
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-238
Summary: Documentation Bug - Retrieving the size of a collection
Type: Improvement
Status: Reopened
Priority: Trivial
Project: Hibernate2
Components:
core
Fix Fors:
2.0.2
Versions:
2.0.2
Assignee:
Reporter: Paul Rivers
Created: Wed, 6 Aug 2003 2:23 PM
Updated: Wed, 6 Aug 2003 5:05 PM
Description:
In the documentation in section 9.13, the is says:
You can count the number of query results without actually returning them:
Integer size = (Integer) s.filter( collection, "select count(*)" ).get(0);
The query, session.filter() returns a collection, not a list! So the call to .get(0) results in a compile error. Instead, the correct way to do it is listed in the faq:
( (Integer) s.createFilter( collection, "select count(*)" ).iterate().next() ).intValue()
---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <leg...@at...> - 2003-08-06 22:09:14
|
Message:
The following issue has been closed.
Resolver: Christian Bauer
Date: Wed, 6 Aug 2003 5:08 PM
Fixed.
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-238
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-238
Summary: Documentation Bug - Retrieving the size of a collection
Type: Improvement
Status: Closed
Priority: Trivial
Resolution: FIXED
Project: Hibernate2
Components:
core
Fix Fors:
2.1
2.0.2
Versions:
2.0.2
Assignee:
Reporter: Paul Rivers
Created: Wed, 6 Aug 2003 2:23 PM
Updated: Wed, 6 Aug 2003 5:08 PM
Description:
In the documentation in section 9.13, the is says:
You can count the number of query results without actually returning them:
Integer size = (Integer) s.filter( collection, "select count(*)" ).get(0);
The query, session.filter() returns a collection, not a list! So the call to .get(0) results in a compile error. Instead, the correct way to do it is listed in the faq:
( (Integer) s.createFilter( collection, "select count(*)" ).iterate().next() ).intValue()
---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <leg...@at...> - 2003-08-06 21:26:14
|
The following comment has been added to this issue:
Author: Paul Rivers
Created: Wed, 6 Aug 2003 4:25 PM
Body:
No, it's not fixed. I'm looking directly at the documentation for 2.0.2
The FIRST entry under section 9.13 is correct, it says:
You can count the number of query results without actually returning them:
( (Integer) session.iterate("select count(*) from ....").next() ).intValue()
The LAST entry under 9.13 says:
You can find the size of a collection without initializing it:
Integer size = (Integer) s.filter( collection, "select count(*)" ).get(0);
Perhaps these are duplicates? Either way, the SECOND listed way is incorrect. (And I am looking at the documentation provided with 2.0.2 - it also exists on the hibernate website docs - http://hibernate.bluemars.net/hib_docs/reference/html/query-language.html#query-language-s11)
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-238
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-238
Summary: Documentation Bug - Retrieving the size of a collection
Type: Improvement
Status: Closed
Priority: Trivial
Resolution: FIXED
Project: Hibernate2
Components:
core
Fix Fors:
2.0.2
Versions:
2.0.2
Assignee:
Reporter: Paul Rivers
Created: Wed, 6 Aug 2003 2:23 PM
Updated: Wed, 6 Aug 2003 3:52 PM
Description:
In the documentation in section 9.13, the is says:
You can count the number of query results without actually returning them:
Integer size = (Integer) s.filter( collection, "select count(*)" ).get(0);
The query, session.filter() returns a collection, not a list! So the call to .get(0) results in a compile error. Instead, the correct way to do it is listed in the faq:
( (Integer) s.createFilter( collection, "select count(*)" ).iterate().next() ).intValue()
---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <leg...@at...> - 2003-08-06 20:53:14
|
Message:
The following issue has been closed.
Resolver: Christian Bauer
Date: Wed, 6 Aug 2003 3:52 PM
This is already fixed, in both the 2.0 and 2.1 branches.
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-238
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-238
Summary: Documentation Bug - Retrieving the size of a collection
Type: Improvement
Status: Closed
Priority: Trivial
Resolution: FIXED
Project: Hibernate2
Components:
core
Fix Fors:
2.0.2
Versions:
2.0.2
Assignee:
Reporter: Paul Rivers
Created: Wed, 6 Aug 2003 2:23 PM
Updated: Wed, 6 Aug 2003 3:52 PM
Description:
In the documentation in section 9.13, the is says:
You can count the number of query results without actually returning them:
Integer size = (Integer) s.filter( collection, "select count(*)" ).get(0);
The query, session.filter() returns a collection, not a list! So the call to .get(0) results in a compile error. Instead, the correct way to do it is listed in the faq:
( (Integer) s.createFilter( collection, "select count(*)" ).iterate().next() ).intValue()
---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <leg...@at...> - 2003-08-06 19:23:14
|
Message: A new issue has been created in JIRA. --------------------------------------------------------------------- View the issue: http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-238 Here is an overview of the issue: --------------------------------------------------------------------- Key: HB-238 Summary: Documentation Bug - Retrieving the size of a collection Type: Improvement Status: Unassigned Priority: Trivial Project: Hibernate2 Components: core Versions: 2.0.2 Assignee: Reporter: Paul Rivers Created: Wed, 6 Aug 2003 2:23 PM Updated: Wed, 6 Aug 2003 2:23 PM Description: In the documentation in section 9.13, the is says: You can count the number of query results without actually returning them: Integer size = (Integer) s.filter( collection, "select count(*)" ).get(0); The query, session.filter() returns a collection, not a list! So the call to .get(0) results in a compile error. Instead, the correct way to do it is listed in the faq: ( (Integer) s.createFilter( collection, "select count(*)" ).iterate().next() ).intValue() --------------------------------------------------------------------- JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira |
93 messages has been excluded from this view by a project administrator.
