You can subscribe to this list here.
2002 |
Jan
(2) |
Feb
(157) |
Mar
(111) |
Apr
(61) |
May
(68) |
Jun
(45) |
Jul
(101) |
Aug
(132) |
Sep
(148) |
Oct
(227) |
Nov
(141) |
Dec
(285) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2003 |
Jan
(518) |
Feb
(462) |
Mar
(390) |
Apr
(488) |
May
(321) |
Jun
(336) |
Jul
(268) |
Aug
(374) |
Sep
(211) |
Oct
(246) |
Nov
(239) |
Dec
(173) |
2004 |
Jan
(110) |
Feb
(131) |
Mar
(85) |
Apr
(120) |
May
(82) |
Jun
(101) |
Jul
(54) |
Aug
(65) |
Sep
(94) |
Oct
(51) |
Nov
(56) |
Dec
(168) |
2005 |
Jan
(146) |
Feb
(98) |
Mar
(75) |
Apr
(118) |
May
(85) |
Jun
(75) |
Jul
(44) |
Aug
(94) |
Sep
(70) |
Oct
(84) |
Nov
(115) |
Dec
(52) |
2006 |
Jan
(113) |
Feb
(83) |
Mar
(217) |
Apr
(158) |
May
(219) |
Jun
(218) |
Jul
(189) |
Aug
(39) |
Sep
(3) |
Oct
(7) |
Nov
(4) |
Dec
(2) |
2007 |
Jan
|
Feb
(2) |
Mar
(7) |
Apr
(3) |
May
(3) |
Jun
(8) |
Jul
(1) |
Aug
(1) |
Sep
|
Oct
(4) |
Nov
(7) |
Dec
|
2008 |
Jan
(1) |
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
(4) |
Sep
|
Oct
(2) |
Nov
(1) |
Dec
|
2009 |
Jan
(6) |
Feb
|
Mar
(1) |
Apr
(2) |
May
(1) |
Jun
(1) |
Jul
(10) |
Aug
|
Sep
(1) |
Oct
(1) |
Nov
|
Dec
(3) |
2010 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
|
Nov
|
Dec
|
2012 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Max R. A. <max...@jb...> - 2006-08-02 15:33:15
|
> Another capability that I would like to see would be to limit > instrumentation to only fields which are defined in a Hibernate mapping. > Currently the instrument tasks do not know anything about the mappings, > so the first change to allow this would be facilitate the passing or > definition of a Configuration into the tasks. The tools already have > such a task used in their ant task stacks. So we would need to decide > whether it makes more sense to move the instrument tasks over to the > tools subproject, or to consume the <configuration/> sub task from tools > into core and make use of it from the instrument tasks. The "easiest" thing codewise is to move the instruments task to hibernate-tools, since the sourrounding <hibernatetool> task is the actual Ant entry point and the <configuration/>, <ejb3configuration>, <annotationconfiguration>, etc. are defined in there. There is also the whole freemarker/templating setup dependency. ...thinking about it an alternative way could be to define a superclass for the current org.hibernate.tool.ant.HibernateToolTask that would just handle the core-built-in ant tasks. then users would have the same ant "API", but users would have to change their <hibernatetool> taskdef to use the "tool" provided tasks. Another context for this alignment/move is the talks we have had about allowing customization of schemaexport/update ...that would also be relevant to ensure it fits into this scheme. -- -- Max Rydahl Andersen callto://max.rydahl.andersen Hibernate ma...@hi... http://hibernate.org JBoss Inc max...@jb... |
From: Steve E. <ste...@jb...> - 2006-08-02 15:14:52
|
So Scott has finished up HHH-1931 in regards to the cglib instrumentation task. =20 The underlying issue was that the javassist and cglib versions did slightly different things in regards to instrumenting field access. Javassist only instrumented access to fields which are declared on the class being transformed; cglib transformed ever field access. Both are actually valuable approaches in different situations. For the time being, the cglib based task was made to not instrument access to fields declared outside the transforming class. I think the opposite approach is valuable when the field's owner is also being instrumented. So another capability to add here is for both of the instrument tasks to be able to instrument access to fields which are declared outside the class being transformed currently as long as the declaring class is also being transformed. Another capability that I would like to see would be to limit instrumentation to only fields which are defined in a Hibernate mapping. Currently the instrument tasks do not know anything about the mappings, so the first change to allow this would be facilitate the passing or definition of a Configuration into the tasks. The tools already have such a task used in their ant task stacks. So we would need to decide whether it makes more sense to move the instrument tasks over to the tools subproject, or to consume the <configuration/> sub task from tools into core and make use of it from the instrument tasks. |
From: Max R. A. <max...@jb...> - 2006-08-02 15:11:41
|
Hi Emmanuel/Steve, The fix I just did for http://opensource.atlassian.com/projects/hibernate/browse/HHH-1963 renders the inheritedMetas in the SecondPass interface useless. (It is only relevant for HbmBinder's Collection secondpass construction anyway. I tried to remove it but then annotations breaks. Should we just let it stick around or remove it ? -- -- Max Rydahl Andersen callto://max.rydahl.andersen Hibernate ma...@hi... http://hibernate.org JBoss Inc max...@jb... |
From: Emmanuel B. <emm...@hi...> - 2006-08-01 18:09:40
|
https://issues.apache.org/jira/browse/DERBY-1624 and also regarding some decent JPA certification https://issues.apache.org/jira/browse/DERBY-1623 There are probably other limitations hidden Steve Ebersole wrote: > I am working on enhancing Derby support a little bit, but have run into > an issue with their syntax that I am unable to figure out. I was hoping > someone on this list was familiar enough with Derby to point me in the > right direction. > > Specifically, I am trying to properly deal with the manner in which > Derby (and also DB2 largely) expects columns to be referenced in certain > clauses. For example, because Hibernate always aliases columns in the > select clause, derby requires that those aliases be used in certain > later clauses. The query I am trying to work through right now is as > follows: > select > model0_.name as col_0_0_, > count(*) as col_1_0_ > from > Model model0_ > group by > model0_.name > having > count(*) > 1 > > However, I get errors from Derby when passing this to the DB: > ERROR 42X04: Column 'MODEL0_.COL_0_0_' is either not in any table in the > FROM list or appears within a join specification and is outside the > scope of the join specification or appears in a HAVING clause and is not > in the GROUP BY list. If this is a CREATE or ALTER TABLE statement then > 'MODEL0_.COL_0_0_' is not a column in the target table. > > If the having clause is removed, the query parses fine; I have tried > various incantations regarding how to define the having clause without > avail. > > This query seems taken almost verbatim from their reference docs, yet I > cannot get this to work... > http://db.apache.org/derby/docs/10.1/ref/rrefselectexpression.html > > Any thoughts? > > _______________________________________________ > hibernate-dev mailing list > hib...@li... > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > |
From: Darryl M. <dar...@ne...> - 2006-08-01 17:46:47
|
A while ago I highlighted a problem with the differences between the documented API and what Hibernate actually does and I'm seeking to an open discussion about the merits and problems to renaming the current #replicate() function to #replicateOrSave() to better identify what it actually does. This is so that a hole can be left open to implement a real #replicate() function which makes contact guarantees that the primary key / OID will be identical even in IDENTITY tables in the replicated object or otherwise it throws an exception. There should also be a feature enquiry function to allow the API programmer to ask the underlying Hibernate implementation to verify if a replication on identity table will work. This would account for JDBC driver vendors and versions and the realtime SQL database server vendor and version. http://www.mail-archive.com/hib...@li.../msg05230.html http://forum.hibernate.org/viewtopic.php?t=949574&highlight= http://www.hibernate.org/hib_docs/v3/api/org/hibernate/Session.html#replicate(java.lang.Object,%20org.hibernate.ReplicationMode) RFC Darryl |
From: Steve E. <ste...@jb...> - 2006-08-01 17:25:08
|
I am working on enhancing Derby support a little bit, but have run into an issue with their syntax that I am unable to figure out. I was hoping someone on this list was familiar enough with Derby to point me in the right direction. Specifically, I am trying to properly deal with the manner in which Derby (and also DB2 largely) expects columns to be referenced in certain clauses. For example, because Hibernate always aliases columns in the select clause, derby requires that those aliases be used in certain later clauses. The query I am trying to work through right now is as follows: select model0_.name as col_0_0_, count(*) as col_1_0_=20 from Model model0_=20 group by model0_.name=20 having count(*) > 1 However, I get errors from Derby when passing this to the DB: ERROR 42X04: Column 'MODEL0_.COL_0_0_' is either not in any table in the FROM list or appears within a join specification and is outside the scope of the join specification or appears in a HAVING clause and is not in the GROUP BY list. If this is a CREATE or ALTER TABLE statement then 'MODEL0_.COL_0_0_' is not a column in the target table. If the having clause is removed, the query parses fine; I have tried various incantations regarding how to define the having clause without avail. This query seems taken almost verbatim from their reference docs, yet I cannot get this to work... http://db.apache.org/derby/docs/10.1/ref/rrefselectexpression.html Any thoughts? |
From: Christian B. <chr...@jb...> - 2006-07-29 07:05:25
|
On Jul 28, 2006, at 2:08 PM, savvy wrote: > View this message in context: Hibernate File storing into database > Sent from the Hibernate forum at Nabble.com. Can anybody take a second and tell these guys to take this down? We don't want a web frontend for the dev mailinglist. |
From: savvy <su...@gm...> - 2006-07-28 20:25:02
|
Hi, There is a requirement like I'v to store file (size less than 100 MB) within a column of a database using hibernate. For that I v used bytea datatype of PostgreSQL. Using CompositeUserType some person thinks it migh be possible. Can any one have better approach to do that. If anyone have already used the CompositeUserType to do that. It'll be definitely helpful. Thanks in advance -- View this message in context: http://www.nabble.com/Hibernate-File-storing-into-database-tf2015071.html#a5538380 Sent from the Hibernate forum at Nabble.com. |
From: Max R. A. <max...@jb...> - 2006-07-27 21:04:54
|
i simply haven't had time. the tablespace thingy won't get applied in this round at least. only the primarykey name etc. might be relevant. /max > Hi > > I submitted a patch regarding named primary-keys and storage option = > meta-attributes some months ago (HHH-1766), but no one has commented o= n = > it. I'm just curious as to 1) if there is a chance that this patch wil= l = > be applied and 2) if there is anything I can do (other than spamming = > this mailing-list :-) to make that more likely to happen. > > Thanks > -Gulli > > > ----------------------------------------------------------------------= --- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to shar= e = > your > opinions on IT & business topics through brief surveys -- and earn cas= h > http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID= =3DDEVDEV > _______________________________________________ > hibernate-devel mailing list > hib...@li... > https://lists.sourceforge.net/lists/listinfo/hibernate-devel -- = -- Max Rydahl Andersen callto://max.rydahl.andersen Hibernate ma...@hi... http://hibernate.org JBoss Inc max...@jb... |
From: Gudlaugur E. <Gud...@ca...> - 2006-07-27 20:58:15
|
Hi A while back, I tweaked Hibernate in order to get it to replicate XML elements properly when an element is referring to another element in the same XML structure. As the code was/is, it only checks for existence in the database, not in the session cache, making it impossible to replicate such elements in a single transaction. Example: <ServiceLineCategory> <categoryId>1000051</categoryId> <categoryName>PDI</categoryName> <description>SBR:Delivery Data</description> <serviceLineDatasources> <ServiceLineDatasource> <datasourceId>1000051</datasourceId> <serviceLineCategory>1000051</serviceLineCategory> <!-- Refers to categoryId above in structure. Need to look it up in the session cache by key. *> <datasourceType>0</datasourceType> </ServiceLineDatasource> </serviceLineDatasources> <serviceLineRuleTemplates/> </ServiceLineCategory> When I updated and merged my code, it turns out that the method in StatefulPersistenceContext I used to check for existence in the session cache, is no longer returning the referred element, even though it is present in the entityEntries map. This is the code snipped I added in DefaultReplicateEventListener: // is there a copy of the object in the session cache already?=20 EntityKey key =3D new EntityKey(id, persister, event.getSession().getEntityMode()); oldVersion =3D event.getSession().getPersistenceContext().getEntity(key); So, this brings me to the question of the relationship between entityEntries and entitiesByKey fields in StatefulPersistenceContext. It seems to me that the nomenclature suggests that these are all supposed to contain the same entities at all times, mapped by different keys. The implementation suggests this as well, but addEntry(...) breaks this by not adding to entitiesByKey. It seems to me that when addEntry(...) is used, it is not possible to look up an entity in the cache by key ?? Any comments on this would be appreciated. |
From: Gudlaugur E. <Gud...@ca...> - 2006-07-27 13:38:39
|
Hi I submitted a patch regarding named primary-keys and storage option = meta-attributes some months ago (HHH-1766), but no one has commented on = it. I'm just curious as to 1) if there is a chance that this patch will be = applied and 2) if there is anything I can do (other than spamming this = mailing-list :-) to make that more likely to happen. Thanks -Gulli |
From: Steve E. <ste...@jb...> - 2006-07-25 18:19:17
|
I guess it depends on which pieces of code you are thinking about specifically in regards to Criteria. For example, for the most part users really should not ever need explicit types any longer when dealing with HQL queries because of the changes I have recently put in place regarding looking at the context in which that "typed node" is used and inferring the proper type based on that; they only ever really need to use a specific type when wanting to do something out of the ordinary (like binding a DateType value to a parameter anticipated as a TimestampType). Would be great to include similar code into Criteria queries; native sql queries would be much tougher.=20 At any rate, I've decided to hold off on this until something other than a minor point release (3.3 maybe?) since it also requires some changes to how the Configuration stuff works). -----Original Message----- From: Max Andersen=20 Sent: Tuesday, July 25, 2006 12:35 PM To: Steve Ebersole Cc: Hibernate development Subject: Re: [Hibernate] Roadmap - components Regarding handling users migration of code then I guess (one of) the worst parts is where users have query/criteria building code that does not have direct access to the session or sessionfactory, but e.g. only have the =20 Query or Criteria. They would have a hard time migrating code since they can't rely on =20 Hibernate.xxx for getting a proper Type. Could be made easier if query and criteria could tell which session they are from ? /max > Well this is just one pre-requisite for "cleaning up" how components are > modeled. Specifically, the piece I want to clean up is the fact that > components are currently handled differently than any other mapping > construct. When components are being parsed and bound (during config > time) they require construction of and access to things that are > typically only available after SF construction (runtime) for all other > mapping contructs. This mis-alignment causes some goofiness in the way > ComponentTypes are built and, even more importantly, some goofiness in > some of the things upon which ComponentTypes currently depend. > > Yes, one of these is how bytecode providers are handled. Another is > PropertyAccessors. Yet another is ComponentTuplizers. > > -----Original Message----- > From: Max Andersen > Sent: Monday, July 24, 2006 2:18 AM > To: Steve Ebersole; Hibernate development > Subject: Re: [Hibernate] Roadmap - components > > >> So that leaves the option of having Types be aware of the session >> factory. Which upon further reflection is not as bad as it sounds, >> because really there are only a few Type implementations that even > need >> access to the session factory at all in any of these methods >> (sqlTypes(), etc exluded). These would be limited to mainly the >> EntityType subclasses, the ComponentType subclasses, and the >> CollectionType subclasses. The essential point being that none of the >> "primitive"/"simple" types are in this category... > > Sounds fair. > >> The one wrinkle in this approach is the various type factory methods > on >> the o.h.Hibernate class. These would need to change signature, or go >> away. > > I guess we could limit these changes to be only for those who really > needed or > would it be better to just get it over with. > > Still, *alot* of code will break for this :( (luckily it is > compile-detectable) > > Is it worth doing this for sessionfactory scoped types ? Do we get more > out > of this than sf-controllable bytecode provider ? (I guess some of the > issues > regarding overriding the default types would also get in here) > > Could we somehow allow both possibilities for the sake of compability ? > > And I know Christian will "love" us for changing this so close to the > book > release ;) > > /max > >> -----Original Message----- >> From: Max Andersen >> Sent: Monday, July 17, 2006 10:51 AM >> To: Steve Ebersole; Hibernate development >> Subject: Re: [Hibernate] Roadmap - components >> >> point taken. >> >>> Well Type and UserType do not necessarily need to be in synch in this >>> particular regard. We could conceivably change Type and then later >>> (i.e. as part of a major release) change the UserType API to align > it. >>> After all the whole point of the UserType stuff was to insulate the >> user >>> from changes in the underlying Type system... >>> >>> -----Original Message----- >>> From: Max Andersen >>> Sent: Monday, July 17, 2006 10:43 AM >>> To: Steve Ebersole; Hibernate development >>> Subject: Re: [Hibernate] Roadmap - components >>> >>> On Mon, 17 Jul 2006 17:41:25 +0200, Steve Ebersole >>> <ste...@jb...> wrote: >>> >>>> Type is *NOT* a public API... >>> >>> but UserType is - don't they need access to this info too ? >>> >>> /max >>> >>>> >>>> -----Original Message----- >>>> From: Max Andersen >>>> Sent: Monday, July 17, 2006 10:38 AM >>>> To: Steve Ebersole; Hibernate development >>>> Subject: Re: [Hibernate] Roadmap - components >>>> >>>> ...but requires changes to public API so probably best suited for >> 3.3. >>>> >>>>> Regarding the component related changes mentioned in the previous >>>>> email... >>>>> >>>>> As I mentioned a lot of the pre-requisite work has already been >>>>> performed on HEAD. I also took the opportunity to refactor the >>>>> packaging of the org.hibernate.tuple package. Specifically, most > of >>>> the >>>>> pre-requisite work was the introduction of the >>>>> o.h.t.component.ComponentMetamodel class. Currently, ComponentType >>>> just >>>>> uses this new class directly. >>>>> >>>>> What needs to happen next, then, is for the introduction of a >>>>> org.hibernate.persister.component.ComponentPersister which is >> managed >>>> as >>>>> part of the session factory much like the other persisters. >>>>> ComponentType will then need to look up its corresponding >>>>> ComponentPersister based on a "role name" and use the capabilities >> of >>>>> that persister. The pattern here is very similar to >>>>> EntityType/EntityPersister. The difficulty I ran into though was >>> that >>>>> ComponentType would then require access to the session factory (in >>>> order >>>>> to locate the persister) from within methods where it is currently >>> not >>>>> passed a reference to the session factory (specifically, this was >>>>> methods like isSame(), isEqual(), compare(), getHashCode(), etc). >>>> This >>>>> gets to more general discussions we have had in the past regarding >>> the >>>>> scoping of Types. The solution is one of two things: >>>>> 1) Devise some sort of scoping scheme where Types can unequivocally >>> be >>>>> "bound" to a session factory. This is obviously difficult given > the >>>>> current Hibernate.LONG, Hibernate.STRING, etc static references. >> One >>>>> thought here would be splitting types (and their interface >>>>> appropriately) to define "static" Types and "scoped" Types... >>>>> 2) Modify the Type interface to accept either a session or a > session >>>>> factory/entity mode combo for most methods (would not really matter >>>> for >>>>> methods like sqlTypes(), etc) >>>>> >>>>> As I mentioned before this then allows us to make the >>>>> 'hibernate.bytecode.provider' and >>>>> 'hibernate.bytecode.use_reflection_optimizer'. Down the road, it >>> also >>>>> allows us to implement discrimination-based inheritance for >>>> components. >>>>> >>>>> >>>>> >>>> >>> >> > ------------------------------------------------------------------------ >>>> - >>>>> Using Tomcat but need to do more? Need to support web services, >>>> security? >>>>> Get stuff done quickly with pre-integrated technology to make your >>> job >>>> >>>>> easier >>>>> Download IBM WebSphere Application Server v.1.0.1 based on Apache >>>>> Geronimo >>>>> >>>> >>> >> > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=3D= 121642 >>>>> _______________________________________________ >>>>> hibernate-devel mailing list >>>>> hib...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/hibernate-devel >>>> >>>> >>>> >>> >>> >>> >> >> >> > > > --=20 -- Max Rydahl Andersen callto://max.rydahl.andersen Hibernate ma...@hi... http://hibernate.org JBoss Inc max...@jb... |
From: Max R. A. <max...@jb...> - 2006-07-25 17:35:59
|
Regarding handling users migration of code then I guess (one of) the wor= st parts is where users have query/criteria building code that does not hav= e direct access to the session or sessionfactory, but e.g. only have the = Query or Criteria. They would have a hard time migrating code since they can't rely on = Hibernate.xxx for getting a proper Type. Could be made easier if query and criteria could tell which session they= = are from ? /max > Well this is just one pre-requisite for "cleaning up" how components a= re > modeled. Specifically, the piece I want to clean up is the fact that > components are currently handled differently than any other mapping > construct. When components are being parsed and bound (during config > time) they require construction of and access to things that are > typically only available after SF construction (runtime) for all other= > mapping contructs. This mis-alignment causes some goofiness in the wa= y > ComponentTypes are built and, even more importantly, some goofiness in= > some of the things upon which ComponentTypes currently depend. > > Yes, one of these is how bytecode providers are handled. Another is > PropertyAccessors. Yet another is ComponentTuplizers. > > -----Original Message----- > From: Max Andersen > Sent: Monday, July 24, 2006 2:18 AM > To: Steve Ebersole; Hibernate development > Subject: Re: [Hibernate] Roadmap - components > > >> So that leaves the option of having Types be aware of the session >> factory. Which upon further reflection is not as bad as it sounds, >> because really there are only a few Type implementations that even > need >> access to the session factory at all in any of these methods >> (sqlTypes(), etc exluded). These would be limited to mainly the >> EntityType subclasses, the ComponentType subclasses, and the >> CollectionType subclasses. The essential point being that none of th= e >> "primitive"/"simple" types are in this category... > > Sounds fair. > >> The one wrinkle in this approach is the various type factory methods > on >> the o.h.Hibernate class. These would need to change signature, or go= >> away. > > I guess we could limit these changes to be only for those who really > needed or > would it be better to just get it over with. > > Still, *alot* of code will break for this :( (luckily it is > compile-detectable) > > Is it worth doing this for sessionfactory scoped types ? Do we get mor= e > out > of this than sf-controllable bytecode provider ? (I guess some of the > issues > regarding overriding the default types would also get in here) > > Could we somehow allow both possibilities for the sake of compability = ? > > And I know Christian will "love" us for changing this so close to the > book > release ;) > > /max > >> -----Original Message----- >> From: Max Andersen >> Sent: Monday, July 17, 2006 10:51 AM >> To: Steve Ebersole; Hibernate development >> Subject: Re: [Hibernate] Roadmap - components >> >> point taken. >> >>> Well Type and UserType do not necessarily need to be in synch in thi= s >>> particular regard. We could conceivably change Type and then later >>> (i.e. as part of a major release) change the UserType API to align > it. >>> After all the whole point of the UserType stuff was to insulate the >> user >>> from changes in the underlying Type system... >>> >>> -----Original Message----- >>> From: Max Andersen >>> Sent: Monday, July 17, 2006 10:43 AM >>> To: Steve Ebersole; Hibernate development >>> Subject: Re: [Hibernate] Roadmap - components >>> >>> On Mon, 17 Jul 2006 17:41:25 +0200, Steve Ebersole >>> <ste...@jb...> wrote: >>> >>>> Type is *NOT* a public API... >>> >>> but UserType is - don't they need access to this info too ? >>> >>> /max >>> >>>> >>>> -----Original Message----- >>>> From: Max Andersen >>>> Sent: Monday, July 17, 2006 10:38 AM >>>> To: Steve Ebersole; Hibernate development >>>> Subject: Re: [Hibernate] Roadmap - components >>>> >>>> ...but requires changes to public API so probably best suited for >> 3.3. >>>> >>>>> Regarding the component related changes mentioned in the previous >>>>> email... >>>>> >>>>> As I mentioned a lot of the pre-requisite work has already been >>>>> performed on HEAD. I also took the opportunity to refactor the >>>>> packaging of the org.hibernate.tuple package. Specifically, most > of >>>> the >>>>> pre-requisite work was the introduction of the >>>>> o.h.t.component.ComponentMetamodel class. Currently, ComponentTyp= e >>>> just >>>>> uses this new class directly. >>>>> >>>>> What needs to happen next, then, is for the introduction of a >>>>> org.hibernate.persister.component.ComponentPersister which is >> managed >>>> as >>>>> part of the session factory much like the other persisters. >>>>> ComponentType will then need to look up its corresponding >>>>> ComponentPersister based on a "role name" and use the capabilities= >> of >>>>> that persister. The pattern here is very similar to >>>>> EntityType/EntityPersister. The difficulty I ran into though was >>> that >>>>> ComponentType would then require access to the session factory (in= >>>> order >>>>> to locate the persister) from within methods where it is currently= >>> not >>>>> passed a reference to the session factory (specifically, this was >>>>> methods like isSame(), isEqual(), compare(), getHashCode(), etc). >>>> This >>>>> gets to more general discussions we have had in the past regarding= >>> the >>>>> scoping of Types. The solution is one of two things: >>>>> 1) Devise some sort of scoping scheme where Types can unequivocall= y >>> be >>>>> "bound" to a session factory. This is obviously difficult given > the >>>>> current Hibernate.LONG, Hibernate.STRING, etc static references. >> One >>>>> thought here would be splitting types (and their interface >>>>> appropriately) to define "static" Types and "scoped" Types... >>>>> 2) Modify the Type interface to accept either a session or a > session >>>>> factory/entity mode combo for most methods (would not really matte= r >>>> for >>>>> methods like sqlTypes(), etc) >>>>> >>>>> As I mentioned before this then allows us to make the >>>>> 'hibernate.bytecode.provider' and >>>>> 'hibernate.bytecode.use_reflection_optimizer'. Down the road, it >>> also >>>>> allows us to implement discrimination-based inheritance for >>>> components. >>>>> >>>>> >>>>> >>>> >>> >> > ----------------------------------------------------------------------= -- >>>> - >>>>> Using Tomcat but need to do more? Need to support web services, >>>> security? >>>>> Get stuff done quickly with pre-integrated technology to make your= >>> job >>>> >>>>> easier >>>>> Download IBM WebSphere Application Server v.1.0.1 based on Apache >>>>> Geronimo >>>>> >>>> >>> >> > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&da= t=3D121642 >>>>> _______________________________________________ >>>>> hibernate-devel mailing list >>>>> hib...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/hibernate-devel >>>> >>>> >>>> >>> >>> >>> >> >> >> > > > -- = -- Max Rydahl Andersen callto://max.rydahl.andersen Hibernate ma...@hi... http://hibernate.org JBoss Inc max...@jb... |
From: Emmanuel B. <emm...@hi...> - 2006-07-25 17:14:36
|
Max Rydahl Andersen wrote: > On Tue, 25 Jul 2006 15:44:28 +0200, Emmanuel Bernard > <emm...@hi...> wrote: > >> Ah my bad, I had a split of personality when I committed it. I'll >> move it today on Annotations. > > Thanks - what is your other persona's name and email address ? Can't tell you that, I'm in a public company now ;-) Test move committed |
From: Steve E. <ste...@jb...> - 2006-07-25 16:31:55
|
Well this is just one pre-requisite for "cleaning up" how components are modeled. Specifically, the piece I want to clean up is the fact that components are currently handled differently than any other mapping construct. When components are being parsed and bound (during config time) they require construction of and access to things that are typically only available after SF construction (runtime) for all other mapping contructs. This mis-alignment causes some goofiness in the way ComponentTypes are built and, even more importantly, some goofiness in some of the things upon which ComponentTypes currently depend. Yes, one of these is how bytecode providers are handled. Another is PropertyAccessors. Yet another is ComponentTuplizers. -----Original Message----- From: Max Andersen=20 Sent: Monday, July 24, 2006 2:18 AM To: Steve Ebersole; Hibernate development Subject: Re: [Hibernate] Roadmap - components > So that leaves the option of having Types be aware of the session > factory. Which upon further reflection is not as bad as it sounds, > because really there are only a few Type implementations that even need > access to the session factory at all in any of these methods > (sqlTypes(), etc exluded). These would be limited to mainly the > EntityType subclasses, the ComponentType subclasses, and the > CollectionType subclasses. The essential point being that none of the > "primitive"/"simple" types are in this category... Sounds fair. > The one wrinkle in this approach is the various type factory methods on > the o.h.Hibernate class. These would need to change signature, or go > away. I guess we could limit these changes to be only for those who really =20 needed or would it be better to just get it over with. Still, *alot* of code will break for this :( (luckily it is =20 compile-detectable) Is it worth doing this for sessionfactory scoped types ? Do we get more out of this than sf-controllable bytecode provider ? (I guess some of the =20 issues regarding overriding the default types would also get in here) Could we somehow allow both possibilities for the sake of compability ? And I know Christian will "love" us for changing this so close to the book =20 release ;) /max > -----Original Message----- > From: Max Andersen > Sent: Monday, July 17, 2006 10:51 AM > To: Steve Ebersole; Hibernate development > Subject: Re: [Hibernate] Roadmap - components > > point taken. > >> Well Type and UserType do not necessarily need to be in synch in this >> particular regard. We could conceivably change Type and then later >> (i.e. as part of a major release) change the UserType API to align it. >> After all the whole point of the UserType stuff was to insulate the > user >> from changes in the underlying Type system... >> >> -----Original Message----- >> From: Max Andersen >> Sent: Monday, July 17, 2006 10:43 AM >> To: Steve Ebersole; Hibernate development >> Subject: Re: [Hibernate] Roadmap - components >> >> On Mon, 17 Jul 2006 17:41:25 +0200, Steve Ebersole >> <ste...@jb...> wrote: >> >>> Type is *NOT* a public API... >> >> but UserType is - don't they need access to this info too ? >> >> /max >> >>> >>> -----Original Message----- >>> From: Max Andersen >>> Sent: Monday, July 17, 2006 10:38 AM >>> To: Steve Ebersole; Hibernate development >>> Subject: Re: [Hibernate] Roadmap - components >>> >>> ...but requires changes to public API so probably best suited for > 3.3. >>> >>>> Regarding the component related changes mentioned in the previous >>>> email... >>>> >>>> As I mentioned a lot of the pre-requisite work has already been >>>> performed on HEAD. I also took the opportunity to refactor the >>>> packaging of the org.hibernate.tuple package. Specifically, most of >>> the >>>> pre-requisite work was the introduction of the >>>> o.h.t.component.ComponentMetamodel class. Currently, ComponentType >>> just >>>> uses this new class directly. >>>> >>>> What needs to happen next, then, is for the introduction of a >>>> org.hibernate.persister.component.ComponentPersister which is > managed >>> as >>>> part of the session factory much like the other persisters. >>>> ComponentType will then need to look up its corresponding >>>> ComponentPersister based on a "role name" and use the capabilities > of >>>> that persister. The pattern here is very similar to >>>> EntityType/EntityPersister. The difficulty I ran into though was >> that >>>> ComponentType would then require access to the session factory (in >>> order >>>> to locate the persister) from within methods where it is currently >> not >>>> passed a reference to the session factory (specifically, this was >>>> methods like isSame(), isEqual(), compare(), getHashCode(), etc). >>> This >>>> gets to more general discussions we have had in the past regarding >> the >>>> scoping of Types. The solution is one of two things: >>>> 1) Devise some sort of scoping scheme where Types can unequivocally >> be >>>> "bound" to a session factory. This is obviously difficult given the >>>> current Hibernate.LONG, Hibernate.STRING, etc static references. > One >>>> thought here would be splitting types (and their interface >>>> appropriately) to define "static" Types and "scoped" Types... >>>> 2) Modify the Type interface to accept either a session or a session >>>> factory/entity mode combo for most methods (would not really matter >>> for >>>> methods like sqlTypes(), etc) >>>> >>>> As I mentioned before this then allows us to make the >>>> 'hibernate.bytecode.provider' and >>>> 'hibernate.bytecode.use_reflection_optimizer'. Down the road, it >> also >>>> allows us to implement discrimination-based inheritance for >>> components. >>>> >>>> >>>> >>> >> > ------------------------------------------------------------------------ >>> - >>>> Using Tomcat but need to do more? Need to support web services, >>> security? >>>> Get stuff done quickly with pre-integrated technology to make your >> job >>> >>>> easier >>>> Download IBM WebSphere Application Server v.1.0.1 based on Apache >>>> Geronimo >>>> >>> >> > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=3D= 121642 >>>> _______________________________________________ >>>> hibernate-devel mailing list >>>> hib...@li... >>>> https://lists.sourceforge.net/lists/listinfo/hibernate-devel >>> >>> >>> >> >> >> > > > --=20 -- Max Rydahl Andersen callto://max.rydahl.andersen Hibernate ma...@hi... http://hibernate.org JBoss Inc max...@jb... |
From: Max R. A. <max...@jb...> - 2006-07-25 13:47:35
|
On Tue, 25 Jul 2006 15:44:28 +0200, Emmanuel Bernard = <emm...@hi...> wrote: > Ah my bad, I had a split of personality when I committed it. I'll move= = > it today on Annotations. Thanks - what is your other persona's name and email address ? /max > > Max Rydahl Andersen wrote: >> >> Hi guys, >> >> subject is breaking the nightly builds and other stuff ;) >> >> The test is relevant but can't be there as it is now. Any suggestions= ? >> Move it to the metadata test suite maybe? >> >> -- >> -- >> Max Rydahl Andersen >> callto://max.rydahl.andersen >> >> Hibernate >> ma...@hi... >> http://hibernate.org >> >> JBoss Inc >> max...@jb... >> >> ---------------------------------------------------------------------= ---- >> Take Surveys. Earn Cash. Influence the Future of IT >> Join SourceForge.net's Techsay panel and you'll get the chance to sha= re = >> your >> opinions on IT & business topics through brief surveys -- and earn ca= sh >> http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CI= D=3DDEVDEV = >> <http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&C= ID=3DDEVDEV> >> _______________________________________________ >> hibernate-devel mailing list >> hib...@li... >> https://lists.sourceforge.net/lists/listinfo/hibernate-devel >> -- = -- Max Rydahl Andersen callto://max.rydahl.andersen Hibernate ma...@hi... http://hibernate.org JBoss Inc max...@jb... |
From: Emmanuel B. <emm...@hi...> - 2006-07-25 13:44:44
|
Ah my bad, I had a split of personality when I committed it. I'll move it today on Annotations. Max Rydahl Andersen wrote: > > Hi guys, > > subject is breaking the nightly builds and other stuff ;) > > The test is relevant but can't be there as it is now. Any suggestions ? > Move it to the metadata test suite maybe? > > -- > -- > Max Rydahl Andersen > callto://max.rydahl.andersen > > Hibernate > ma...@hi... > http://hibernate.org > > JBoss Inc > max...@jb... > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to > share your > opinions on IT & business topics through brief surveys -- and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > <http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV> > _______________________________________________ > hibernate-devel mailing list > hib...@li... > https://lists.sourceforge.net/lists/listinfo/hibernate-devel > |
From: Max R. A. <max...@jb...> - 2006-07-25 05:00:19
|
Hi guys, subject is breaking the nightly builds and other stuff ;) The test is relevant but can't be there as it is now. Any suggestions ? Move it to the metadata test suite maybe? -- -- Max Rydahl Andersen callto://max.rydahl.andersen Hibernate ma...@hi... http://hibernate.org JBoss Inc max...@jb... |
From: Max R. A. <max...@jb...> - 2006-07-24 16:40:15
|
oh and of course Hibernate Tools relies on being able to access a fully build Configuration without any need of reflection (assuming the types have been specified in the mappings by the user) A request for enhancement would be somehow for me to hook into these reflection calls so i could provide my own "worldview" to it e.g. from Eclipse's sourcemodel (it is definitly not a requirement; but could give me some nice ways of building a SessionFactory without the actual classes having to be loaded) /max > Hi Steve, > > Here is a list of the "tricks" I know about with respect to what I and > Emmanuel do in JDBCMetaDataConfiguration and AnnotationConfiguration. > What i mainly did were to check what methods we override and what was > done > in them (and in some cases not done) > > Emmanuel please verify that i'm close to the truth regarding your usage > of > "tricks" :) > > JDBCMetaDataConfiguration: > > Overrides secondPassCompileForeignKeys(Table table, Set done) > This is done to avoid creating foreignkeys in the metamdoel which is > actually NOT in the database. > > OverridesparseMappingElement(Element subelement, String name) > Done to be able to get all the settings without loading any mappings. > Thus users can just say "use this set of hibernate configuration files" > for > reverse engineering and the existing mappings will be ignored. > > + I have my own SecondPass subclass for Collections (might add more in > future) > > AnnotationConfiguration > > Overrides add(org.dom4j.Document doc) > Done to detect if it is a hibernate-mapping or EJB3 entity-mappings > document and do things accordingly. > > Overrides addInputStream(InputStream xmlInputStream) > Done to configure XML schema parsing. > > Overrides reset() > For additional bookkeeping reset > > Overrides secondPassCompile() > To build up mappings (not sure if this one can handles multiple calls ? > Emmanuel) > > Overrides setCollectionCacheConcurrencyStrategy(String collectionRole, > String concurrencyStrategy, String region) > To have its own cache info > > + Emmanuel have multiple custom secondpass subclasses > > /max > > > > > > > > > -- -- Max Rydahl Andersen callto://max.rydahl.andersen Hibernate ma...@hi... http://hibernate.org JBoss Inc max...@jb... |
From: Max R. A. <max...@jb...> - 2006-07-24 16:29:15
|
Hi Steve, Here is a list of the "tricks" I know about with respect to what I and Emmanuel do in JDBCMetaDataConfiguration and AnnotationConfiguration. What i mainly did were to check what methods we override and what was done in them (and in some cases not done) Emmanuel please verify that i'm close to the truth regarding your usage of "tricks" :) JDBCMetaDataConfiguration: Overrides secondPassCompileForeignKeys(Table table, Set done) This is done to avoid creating foreignkeys in the metamdoel which is actually NOT in the database. OverridesparseMappingElement(Element subelement, String name) Done to be able to get all the settings without loading any mappings. Thus users can just say "use this set of hibernate configuration files" for reverse engineering and the existing mappings will be ignored. + I have my own SecondPass subclass for Collections (might add more in future) AnnotationConfiguration Overrides add(org.dom4j.Document doc) Done to detect if it is a hibernate-mapping or EJB3 entity-mappings document and do things accordingly. Overrides addInputStream(InputStream xmlInputStream) Done to configure XML schema parsing. Overrides reset() For additional bookkeeping reset Overrides secondPassCompile() To build up mappings (not sure if this one can handles multiple calls ? Emmanuel) Overrides setCollectionCacheConcurrencyStrategy(String collectionRole, String concurrencyStrategy, String region) To have its own cache info + Emmanuel have multiple custom secondpass subclasses /max -- -- Max Rydahl Andersen callto://max.rydahl.andersen Hibernate ma...@hi... http://hibernate.org JBoss Inc max...@jb... |
From: <ja...@he...> - 2006-07-24 12:21:01
|
Here you go: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1934 it's only three lines, but enhances two logging entries, so will I have three lines free on the next issue ;-) ?? anyway, I'd really like to see the logging on those issues improved, since I've spent quite some time to hunt them down (I suppose other people will have the same problems). thanks for the good work :-) Max Rydahl Andersen wrote: > > submit a patch in jira that sends it to log.trace (in less than 4 individual lines ;) and we will consider it. > > /max > >> Hi, >> >> I'm trying to debug/fix Hibernate messages like "org.hibernate.NonUniqueObjectException: a different object with the same identifier value was already associated with the session: "... and I find the default exception logging in AbstractSaveEventListener#performSave not sufficient. I've added some System.err.printlns() with the information I typically need. It would be great if this debug info would make it somehow into the latest SVN. >> >> Rgds >> Holger >> >> /** >> * Ppepares the save call by checking the session caches for a pre-existing >> * entity and performing any lifecycle callbacks. >> * @param entity The entity to be saved. >> * @param id The id by which to save the entity. >> * @param persister The entity's persister instance. >> * @param useIdentityColumn Is an identity column in use? >> * @param source The session from which the event originated. >> * @param requiresImmediateIdAccess does the event context require >> * access to the identifier immediately after execution of this method (if >> * not, post-insert style id generators may be postponed if we are outside >> * a transaction). >> * @return The id used to save the entity; may be null depending on the >> * type of id generator used and the requiresImmediateIdAccess value >> * @throws HibernateException >> */ >> protected Serializable performSave( >> Object entity, >> Serializable id, >> EntityPersister persister, >> boolean useIdentityColumn, >> Object anything, >> EventSource source, >> boolean requiresImmediateIdAccess) >> throws HibernateException { >> >> if ( log.isTraceEnabled() ) { >> log.trace( >> "saving " + >> MessageHelper.infoString( persister, id, source.getFactory() ) >> ); >> } >> >> EntityKey key; >> if ( !useIdentityColumn ) { >> key = new EntityKey( id, persister, source.getEntityMode() ); >> Object old = source.getPersistenceContext().getEntity(key); >> if (old != null) { >> if ( source.getPersistenceContext().getEntry(old).getStatus() == Status.DELETED ) { >> source.forceFlush( source.getPersistenceContext().getEntry(old) ); >> } >> else { >> System.err.println("old: " + old); >> System.err.println("old.class: " + old.getClass()); >> System.err.println("entity: " + entity); >> System.err.println("entity.class: " + entity.getClass()); >> System.err.println("id: " + id); >> throw new NonUniqueObjectException( id, persister.getEntityName() ); >> } >> } >> persister.setIdentifier(entity, id, source.getEntityMode()); >> } >> else { >> key = null; >> } >> >> if ( invokeSaveLifecycle(entity, persister, source) ) { >> return id; //EARLY EXIT >> } >> >> return performSaveOrReplicate( >> entity, >> key, >> persister, >> useIdentityColumn, >> anything, >> source, >> requiresImmediateIdAccess >> ); >> } >> > > > -- Holger Haag Geschäftsführer SoftConEx GmbH Zossener Straße 55 D-10961 Berlin Telefon: ++49 (0) 30 63901692 Fax: ++49 (0) 30 63901669 Mobil: ++49 (0) 1511 7810317 -- Echte DSL-Flatrate dauerhaft für 0,- Euro*. Nur noch kurze Zeit! "Feel free" mit GMX DSL: http://www.gmx.net/de/go/dsl |
From: Max R. A. <max...@jb...> - 2006-07-24 07:18:11
|
> So that leaves the option of having Types be aware of the session > factory. Which upon further reflection is not as bad as it sounds, > because really there are only a few Type implementations that even nee= d > access to the session factory at all in any of these methods > (sqlTypes(), etc exluded). These would be limited to mainly the > EntityType subclasses, the ComponentType subclasses, and the > CollectionType subclasses. The essential point being that none of the= > "primitive"/"simple" types are in this category... Sounds fair. > The one wrinkle in this approach is the various type factory methods o= n > the o.h.Hibernate class. These would need to change signature, or go > away. I guess we could limit these changes to be only for those who really = needed or would it be better to just get it over with. Still, *alot* of code will break for this :( (luckily it is = compile-detectable) Is it worth doing this for sessionfactory scoped types ? Do we get more = out of this than sf-controllable bytecode provider ? (I guess some of the = issues regarding overriding the default types would also get in here) Could we somehow allow both possibilities for the sake of compability ? And I know Christian will "love" us for changing this so close to the bo= ok = release ;) /max > -----Original Message----- > From: Max Andersen > Sent: Monday, July 17, 2006 10:51 AM > To: Steve Ebersole; Hibernate development > Subject: Re: [Hibernate] Roadmap - components > > point taken. > >> Well Type and UserType do not necessarily need to be in synch in this= >> particular regard. We could conceivably change Type and then later >> (i.e. as part of a major release) change the UserType API to align it= . >> After all the whole point of the UserType stuff was to insulate the > user >> from changes in the underlying Type system... >> >> -----Original Message----- >> From: Max Andersen >> Sent: Monday, July 17, 2006 10:43 AM >> To: Steve Ebersole; Hibernate development >> Subject: Re: [Hibernate] Roadmap - components >> >> On Mon, 17 Jul 2006 17:41:25 +0200, Steve Ebersole >> <ste...@jb...> wrote: >> >>> Type is *NOT* a public API... >> >> but UserType is - don't they need access to this info too ? >> >> /max >> >>> >>> -----Original Message----- >>> From: Max Andersen >>> Sent: Monday, July 17, 2006 10:38 AM >>> To: Steve Ebersole; Hibernate development >>> Subject: Re: [Hibernate] Roadmap - components >>> >>> ...but requires changes to public API so probably best suited for > 3.3. >>> >>>> Regarding the component related changes mentioned in the previous >>>> email... >>>> >>>> As I mentioned a lot of the pre-requisite work has already been >>>> performed on HEAD. I also took the opportunity to refactor the >>>> packaging of the org.hibernate.tuple package. Specifically, most o= f >>> the >>>> pre-requisite work was the introduction of the >>>> o.h.t.component.ComponentMetamodel class. Currently, ComponentType= >>> just >>>> uses this new class directly. >>>> >>>> What needs to happen next, then, is for the introduction of a >>>> org.hibernate.persister.component.ComponentPersister which is > managed >>> as >>>> part of the session factory much like the other persisters. >>>> ComponentType will then need to look up its corresponding >>>> ComponentPersister based on a "role name" and use the capabilities > of >>>> that persister. The pattern here is very similar to >>>> EntityType/EntityPersister. The difficulty I ran into though was >> that >>>> ComponentType would then require access to the session factory (in >>> order >>>> to locate the persister) from within methods where it is currently >> not >>>> passed a reference to the session factory (specifically, this was >>>> methods like isSame(), isEqual(), compare(), getHashCode(), etc). >>> This >>>> gets to more general discussions we have had in the past regarding >> the >>>> scoping of Types. The solution is one of two things: >>>> 1) Devise some sort of scoping scheme where Types can unequivocally= >> be >>>> "bound" to a session factory. This is obviously difficult given th= e >>>> current Hibernate.LONG, Hibernate.STRING, etc static references. > One >>>> thought here would be splitting types (and their interface >>>> appropriately) to define "static" Types and "scoped" Types... >>>> 2) Modify the Type interface to accept either a session or a sessio= n >>>> factory/entity mode combo for most methods (would not really matter= >>> for >>>> methods like sqlTypes(), etc) >>>> >>>> As I mentioned before this then allows us to make the >>>> 'hibernate.bytecode.provider' and >>>> 'hibernate.bytecode.use_reflection_optimizer'. Down the road, it >> also >>>> allows us to implement discrimination-based inheritance for >>> components. >>>> >>>> >>>> >>> >> > ----------------------------------------------------------------------= -- >>> - >>>> Using Tomcat but need to do more? Need to support web services, >>> security? >>>> Get stuff done quickly with pre-integrated technology to make your >> job >>> >>>> easier >>>> Download IBM WebSphere Application Server v.1.0.1 based on Apache >>>> Geronimo >>>> >>> >> > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&da= t=3D121642 >>>> _______________________________________________ >>>> hibernate-devel mailing list >>>> hib...@li... >>>> https://lists.sourceforge.net/lists/listinfo/hibernate-devel >>> >>> >>> >> >> >> > > > -- = -- Max Rydahl Andersen callto://max.rydahl.andersen Hibernate ma...@hi... http://hibernate.org JBoss Inc max...@jb... |
From: Sunny <shi...@ya...> - 2006-07-22 09:06:02
|
I am using a named query in my .hbm file: <query name="queryName"> <![CDATA[ select itemModel.productId , count(inventoryItemModel.itemId) from ItemModel itemModel, InventoryItemModel inventoryItemModel where inventoryItemModel.itemId = itemModel.itemId and inventoryItemModel.status = 1501 and itemModel.productId = ? group by itemModel.productId, itemModel.itemId ]]></query> This is working fine.However i need to write an outer query to get the minimum count. This is what I want: select productId, min(ABC) from <query name="queryName"> <![CDATA[ select itemModel.productId , count(inventoryItemModel.itemId) ABC from ItemModel itemModel, InventoryItemModel inventoryItemModel where inventoryItemModel.itemId = itemModel.itemId and inventoryItemModel.status = 1501 and itemModel.productId = ? group by itemModel.productId, itemModel.itemId ) group by facility_id, product_id ]]></query> Giving alias ABC throws error "Error in named query".Is there any other way to specify an alias ? Please help me to solve this.Thanks in advance. -- View this message in context: http://www.nabble.com/giving-alias-in-Named-Query-tf1983665.html#a5444429 Sent from the Hibernate forum at Nabble.com. |
From: Steve E. <ste...@jb...> - 2006-07-21 16:48:40
|
Regarding the HQL translator related changes mentioned in the previous email... Mainly, this is involving a fairly large scale refactoring of the Antlr grammars and the associated code. The first aspect was previously discussed on this list, so I won't go into all the gory details. Basically, the current Antlr-based translator translates an HQL query in 3 phases where each phase is represented by one of the grammars. As part of the refactoring, it was decided to move to a 4 phase approach. Essentially, the old second phase will be split out into 2 separate phases (that's slightly simplified, but the basic gist). Another aspect was overall simplification of the AST trees. This is work that has been on going, separated out on the HQL_ANTLR_2 branch in SVN. The focus of the work on that branch thus far has been the first and second phases. This was all being done in an effort to add specific new capabilities to HQL as well as make it easier moving forward to add even more new stuff. For example, one of the new features (that is essentially done on that branch) is the capability to perform "ad hoc" joining. Another is UNION and MINUS capabilities. Another thing that was done was to change the manner in which "property paths" are resolved. The previous version delegated to the individual nodes that made up the path after the entire path had been recognized. That put a lot of responsibility on the nodes in terms of knowing where they were located within the overall statement structure since that has a bearing on how the path resolution needs to be handled. I am not completely satisfied with some of the details about how this is currently being done on the branch, but it's pretty close to how I see this being done in the eventual solution. The one thing that is causing serious issues with the current approach is index operators; they throw a hugely gigantic monkey wrench into that processing currently :( |
From: Max R. A. <max...@jb...> - 2006-07-21 14:43:01
|
submit a patch in jira that sends it to log.trace (in less than 4 = individual lines ;) and we will consider it. /max > Hi, > > I'm trying to debug/fix Hibernate messages like = > "org.hibernate.NonUniqueObjectException: a different object with the = > same identifier value was already associated with the session: "... an= d = > I find the default exception logging in = > AbstractSaveEventListener#performSave not sufficient. I've added some = = > System.err.printlns() with the information I typically need. It would = be = > great if this debug info would make it somehow into the latest SVN. > > Rgds > Holger > > /** > * Ppepares the save call by checking the session caches for a = > pre-existing > * entity and performing any lifecycle callbacks. > * @param entity The entity to be saved. > * @param id The id by which to save the entity. > * @param persister The entity's persister instance. > * @param useIdentityColumn Is an identity column in use? > * @param source The session from which the event originated. > * @param requiresImmediateIdAccess does the event context require > * access to the identifier immediately after execution of this metho= d = > (if > * not, post-insert style id generators may be postponed if we are = > outside > * a transaction). > * @return The id used to save the entity; may be null depending on t= he > * type of id generator used and the requiresImmediateIdAccess value > * @throws HibernateException > */ > protected Serializable performSave( > Object entity, > Serializable id, > EntityPersister persister, > boolean useIdentityColumn, > Object anything, > EventSource source, > boolean requiresImmediateIdAccess) > throws HibernateException { > > if ( log.isTraceEnabled() ) { > log.trace( > "saving " + > MessageHelper.infoString( persister, id, source.getFactory() ) > ); > } > = > EntityKey key; > if ( !useIdentityColumn ) { > key =3D new EntityKey( id, persister, source.getEntityMode() ); > Object old =3D source.getPersistenceContext().getEntity(key); > if (old !=3D null) { > if ( source.getPersistenceContext().getEntry(old).getStatus() =3D=3D= = > Status.DELETED ) { > source.forceFlush( source.getPersistenceContext().getEntry(old) )= ; > } > else { > System.err.println("old: " + old); > System.err.println("old.class: " + old.getClass()); > System.err.println("entity: " + entity); > System.err.println("entity.class: " + entity.getClass()); > System.err.println("id: " + id); > throw new NonUniqueObjectException( id, persister.getEntityName()= ); > } > } > persister.setIdentifier(entity, id, source.getEntityMode()); > } > else { > key =3D null; > } > = > if ( invokeSaveLifecycle(entity, persister, source) ) { > return id; //EARLY EXIT > } > > return performSaveOrReplicate( > entity, > key, > persister, > useIdentityColumn, > anything, > source, > requiresImmediateIdAccess > ); > } > -- = -- Max Rydahl Andersen callto://max.rydahl.andersen Hibernate ma...@hi... http://hibernate.org JBoss Inc max...@jb... |