[Hibernate] hibernate-sybase-testsuite Build Timed Out
View results here -> http://cruisecontrol.jboss.com/cc/buildresults/hibernate-sybase-testsuite?log=log20060716230837 BUILD TIMED OUTAnt Error Message:build timeoutDate of build:07/16/2006 23:08:37Time to build: Unit Tests: (0) Total Errors and Failures: (0) Modifications since last build:(first 50 of 0) - 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=lnkkid=120709bid=263057dat=121642 ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel
[Hibernate] hibernate-oracle10-testsuite Build Completed With Testsuite Errors
View results here -> http://cruisecontrol.jboss.com/cc/buildresults/hibernate-oracle10-testsuite?log=log20060717020838 TESTS FAILEDAnt Error Message:/home/cruisecontrol/work/scripts/build-hibernate-db-matrix.xml:101: The following error occurred while executing this line: /home/cruisecontrol/work/scripts/build-hibernate-db-matrix.xml:78: The following error occurred while executing this line: /home/cruisecontrol/work/scripts/build-common-targets.xml:11: Build Successful - Tests completed with errors or failures.Date of build:07/17/2006 02:08:38Time to build:17 minutes 12 seconds Unit Tests: (860) Total Errors and Failures: (13)testSequenceIdentityGeneratororg.hibernate.test.generatedkeys.seqidentity.SequenceIdentityTesttestParameterTypeMismatchFailsorg.hibernate.test.hql.ASTParserLoadingTesttestCriteriaAggregationReturnTypeFailureExpectedorg.hibernate.test.hql.CriteriaHQLAlignmentTesttestReturnPropertyComponentRenameorg.hibernate.test.legacy.SQLLoaderTesttestReadOnlyOnProxiesFailureExpectedorg.hibernate.test.readonly.ReadOnlyTesttestCompositeIdJoinsFailureExpectedorg.hibernate.test.sql.GeneralTesttestEmptyInListFailureExpectedorg.hibernate.test.hql.HQLTesttestMaxindexHqlFunctionInElementAccessorFailureExpectedorg.hibernate.test.hql.HQLTesttestMultipleElementAccessorOperatorsFailureExpectedorg.hibernate.test.hql.HQLTesttestKeyManyToOneJoinFailureExpectedorg.hibernate.test.hql.HQLTesttestDuplicateExplicitJoinFailureExpectedorg.hibernate.test.hql.HQLTesttestOptimisticLockDirtyDeleteFailureExpectedorg.hibernate.test.optlock.OptimisticLockTesttestOptimisticLockAllDeleteFailureExpectedorg.hibernate.test.optlock.OptimisticLockTest Modifications since last build:(first 50 of 0) - 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=lnkkid=120709bid=263057dat=121642 ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel
[Hibernate] Unexpected token: GENERATED in statement
Hi,I am a newbie to hibernate.I am getting the following exception: DEBUG SchemaExport:301 - create table EVENTS (EVENTS_ID bigint generated by default as identity (start with 1), EVENTS_DATE timestamp, EVENTS_TITLE varchar(255) not null, primary key (EVENTS_ID))ERROR SchemaExport:272 - Unsuccessful: create table EVENTS (EVENTS_ID bigint generated by default as identity (start with 1), EVENTS_DATE timestamp, EVENTS_TITLE varchar(255) not null, primary key (EVENTS_ID))ERROR SchemaExport:273 - Unexpected token: GENERATED in statement [create table EVENTS (EVENTS_ID bigint generated by default as identity (start with 1), EVENTS_DATE timestamp, EVENTS_TITLE varchar(255) not null, primary key (EVENTS_ID))]Following is the snapshot of the corresponding mapping: class name="org.domain.events.Event" table="EVENTS" id name="id" column="EVENTS_ID" generator class="native"/generator /id property name="date" type="timestamp" column="EVENTS_DATE"/ property name="title" not-null="true" column="EVENTS_TITLE"/ /classBut when I change the generator class from native to increment it runs fine. I am using HSQL DB as my database.Could anyone please point me the problem.Regards, Subhra Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail Beta. - 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=lnkkid=120709bid=263057dat=121642 ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel
Re: [Hibernate] Unexpected token: GENERATED in statement
use user forum at forum.hibernate.org for user questions - this is for hibernate core development. /max Hi, I am a newbie to hibernate. I am getting the following exception: DEBUG SchemaExport:301 - create table EVENTS (EVENTS_ID bigint generated by default as identity (start with 1), EVENTS_DATE timestamp, EVENTS_TITLE varchar(255) not null, primary key (EVENTS_ID)) ERROR SchemaExport:272 - Unsuccessful: create table EVENTS (EVENTS_ID bigint generated by default as identity (start with 1), EVENTS_DATE timestamp, EVENTS_TITLE varchar(255) not null, primary key (EVENTS_ID)) ERROR SchemaExport:273 - Unexpected token: GENERATED in statement [create table EVENTS (EVENTS_ID bigint generated by default as identity (start with 1), EVENTS_DATE timestamp, EVENTS_TITLE varchar(255) not null, primary key (EVENTS_ID))] Following is the snapshot of the corresponding mapping: class name=org.domain.events.Event table=EVENTS id name=id column=EVENTS_ID generator class=native/generator /id property name=date type=timestamp column=EVENTS_DATE/ property name=title not-null=true column=EVENTS_TITLE/ /class But when I change the generator class from native to increment it runs fine. I am using HSQL DB as my database. Could anyone please point me the problem. Regards, Subhra - Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail Beta. -- -- Max Rydahl Andersen callto://max.rydahl.andersen Hibernate [EMAIL PROTECTED] http://hibernate.org JBoss Inc [EMAIL PROTECTED] - 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=lnkkid=120709bid=263057dat=121642 ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel
[Hibernate] hibernate-timesten-testsuite Build Completed With Testsuite Errors
View results here -> http://cruisecontrol.jboss.com/cc/buildresults/hibernate-timesten-testsuite?log=log20060717022623 TESTS FAILEDAnt Error Message:/home/cruisecontrol/work/scripts/build-hibernate-db-matrix.xml:94: The following error occurred while executing this line: /home/cruisecontrol/work/scripts/build-hibernate-db-matrix.xml:78: The following error occurred while executing this line: /home/cruisecontrol/work/scripts/build-common-targets.xml:11: Build Successful - Tests completed with errors or failures.Date of build:07/17/2006 02:26:23Time to build:24 minutes 27 seconds Unit Tests: (858) Total Errors and Failures: (215)
Re: [Hibernate] Hibernate Lucene integration
Any Default Good question, I don't think we should index all properties by default: I guess we should ask that tot he Lucene community. I think no-index is an apropriate default; but maybe a @IndexAll would be relevant ? (not sure though) As for the bridges (ie types), they are defaulted, there is an heuristic guess mechanism. sounds good. The default is FSDirectory with the base directory being .. RAMDirectory is of little use except for some specific usecases and for unit testing Makes sense. I'm not a big fan of exposing the Lucene result itself but the relevance is something useful, I need to thing about that: the main problem is that I currently hide some of the plumbering to the user esp the searcher opening and closing, by doing so, there is no way to give the Hits (Lucene results). The ordering is preserved when returned by Hibernate. How about turning this upside-down and let the user execute the query and thus he have access to the lucene API query and could do something like: session.createLucenceQuery(lucenceapiquery q).list() ? why session.index() a specific operation? Here is my reasoning: - using a lucene query to index a non index object is going to be hard since the lucene query will not return the object in the first place ;-) details ;) - using a regular Hibernate query + a flag to index the objects suffers the OOME issue unless we use the stateless session. If I use the stateless session, I can't use the event system... Why does this give OOME ? If you query for one object + flag it should be just as heavy/light as index(), right ? - From what I've seen and guessed, what you want to (re)index is very business specific and can be way more complex than just a query mkay. Session delegation and callbacks Yes but Event Listeners are the current way to have a callback to the session. Event Listeners are stateless, the state being part of the events. What we need is a way to push / keep some informations at the event / PersistenceContext level. The SessionDelegate would be another way to keep some state but make it hard to push the info to the eventlisteners Yes, that would allow you to the #3 i talked about - having a SessionDelegate that the underlying Session could call back to with enough context to allow you to maintain it. /max Max Rydahl Andersen wrote: Hi Emmanuel, Here are my comments (sorry if something is obvious from looking at the code, but haven't had time to look into the details yet) *Concepts* Each time you change an object state, the lucene index is updated and kept in sync. This is done through the Hibernate event system. Ok - sounds cool. The index is updated at flush or commit time ? (i assume commit) Whether an entity is indexed or not and whether a property is indexed or not is defined through annotations. Any defaults? You can also search through your domain model using Lucene and retrieve managed objects. The whole idea here is to do a nice integration between the search engine and the ORM without loosing the search engine power, hence most of the API remains. To sum up, query Lucene, get managed object back. Cool. *Mapping* A given entity is mapped to an index. A lucene index is stored in a Directory, a Directory is a Lucnee abstract concept for index storage system. It can be a memory directory (RAMDirectory), a file system directory (FSDirectory) or any other kind of backend. Hibernate Lucene introduce the notion of DirectoryProvider that you can configure and define on a per entity basis (and wich is defaulted defaulted). The concept is very similar to ConnectionProvider. defaulted defaulted ? (defaulted to RAMDirectory maybe ?) Lucene only works with Strings, so you can define a @FieldBridge which transform a java property into a Lucene Field (and potentially vice-versa). A more simple (useful?) version handle the transformation of a java property into a String. Some built-in FieldBrigde exists. @FieldBridge is very much like an Hibernate Type. Esp I introduced the notion of precision in dates (year, month, .. second, millisecond). This FieldBridge and StringBridge gives a lot of flexibility in the way to design the property indexing. Sounds like a good thing. *Querying* I've introduced the notion of LuceneSession which implements Session and actually delegates to a regular Hibernate Session. This lucene session has a /createLuceneQuery()/ method and a /index()/ method. /session.createLuceneQuery(lucene.Query, Class[])/ takes a Lucene query as a parameter and the list of targeted entities. Using a Lucene query as a parameter gives the full Lucene flexibility (no abstraction on top of it). An /org.hibernate.Query/ object is returned. You can (must) use pagination. A Lucene query also return the number of matching results (regardless of the pagination): query.resultSize()
[Hibernate] Unsubscribe
Unsubscribe - 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=lnkkid=120709bid=263057dat=121642 ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel
[Hibernate] hibernate lazy load
Hi all. I have a mapped class that has two many-to-one relations. Im using spring HibernateDaoSupport class to retrieve the data from the hibernate session and i have a problem when i get this class data. Im not able to get the data from the two many-to-one relations. i have solved it with the default-lazy=false attribute in the hbm file but i want to know if there is abetter solution. it has to be coded in the dao class because the HibermnateDaoSupport closes the hibernate session... I have tried with the join keyword in gthe query without success. Any idea?? thx -- View this message in context: http://www.nabble.com/hibernate-lazy-load-tf1954685.html#a5360743 Sent from the Hibernate forum at Nabble.com. - 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=lnkkid=120709bid=263057dat=121642 ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel
Re: [Hibernate] hibernate lazy load
use user forum at forum.hibernate.org for user questions - this is for hibernate core development. /max Hi all. I have a mapped class that has two many-to-one relations. Im using spring HibernateDaoSupport class to retrieve the data from the hibernate session and i have a problem when i get this class data. Im not able to get the data from the two many-to-one relations. i have solved it with the default-lazy=false attribute in the hbm file but i want to know if there is abetter solution. it has to be coded in the dao class because the HibermnateDaoSupport closes the hibernate session... I have tried with the join keyword in gthe query without success. Any idea?? thx -- -- Max Rydahl Andersen callto://max.rydahl.andersen Hibernate [EMAIL PROTECTED] http://hibernate.org JBoss Inc [EMAIL PROTECTED] - 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=lnkkid=120709bid=263057dat=121642 ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel
Re: [Hibernate] hibernate lazy load
OK i didnt know. I have tried to register in the forum.hibernate.com but it throws an error and it says that my user is inactive. Do you know how can i contact with the administrator so he'll active my account? thx -- View this message in context: http://www.nabble.com/hibernate-lazy-load-tf1954685.html#a5360961 Sent from the Hibernate forum at Nabble.com. - 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=lnkkid=120709bid=263057dat=121642 ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel
[Hibernate] Roadmap
Now that 3.2.0.ga is imminent, here are the things which are currently underway, or which I would like to start soon: 1) Antlr query translator redesign. The original Antlr-based translator was a great first cut and showed us the usefulness of Antlr for this task; in many ways it ways a learning experience. Now, it is time to take those experiences and redesign how the translator works in a few areas and to add some significant enhancements. This will be the subject of a separate email a little later. This work is already well underway on a separate branch in SVN. 2) Adding the notion of a component persister. The goal here is to move most of the logic off of ComponentType to a persister managed by the session factory. The impetus being twofold: a) certain hibernate configuration parameters are currently considered global because of the way ComponentType currently works; the two most annoying being 'hibernate.bytecode.use_reflection_optimizer' and 'hibernate.bytecode.provider'. These changes would allow both of those settings to become session factory scoped values. b) general code cleanup and encapsulation; this aligns with how entities are managed by the EntityTypes. More about this in a later email also. Note that many pre-requisite changes for this have already been made on HEAD (i.e. the inclusion of the o.h.tuple.ComponentMetamodel). 3) Redefine how CacheProvider/Cache work. The main goal here is to have CacheProvider be able to create Cache instances configured for how Hibernate uses the different second level (L2) cache regions. There are 4 regions types each with slightly different usage semantics: a) entity data cache - used to cache entity tuple state b) collection cache - used to cache collection state c) query cache - used to cache query results d) invalidation or timestamps cache 4) Criteria API enhancements: a) I'd like to get everything that is currently possible in HQL as a capability in Criteria queries. Ideally, I'd like to re-use some of the changes being made to the Antlr query translator to facilitate these enhancements. b) statistics collection - the only real possibility I see here is to expose the ability to name criteria queries and expose the stats based on the given name. 5) Completion of the EntityMode and Tuplizer capabilities. This has been hanging around for a while now. There are a couple of specific things we need to finish off here: a) we know that recognizing the concrete type of polymorphic associations is completely broken when using the dom4j entity mode. This is because we currently do not require that node names be unique and we also do not require that the DOM node contain any type of discrimination value. Need to decide on the approach that allows this to work and that is hopefully non-invasive. b) allow user defined entity modes. The infrastructure for allowing this is now in place in HEAD. However, there are currently a lot of places in the code base that assume the entity modes are enums and do == type comparisions. We either need to change all those, or somehow make the user register their custom entity modes. Plus the DTD then needs to be updated to support this. Another thing to discuss is whether these should be bundled in the 3.2.x series, or to go with a 3.3.x. I personally vote to go with a 3.3.x series as 3.2.x was essentially targetting JPA-related work. If we agree for 3.3, then I'll branch HEAD off onto a 3.2 specific branch and we can start to use HEAD for 3.3 work. Thoughts? - 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=lnkkid=120709bid=263057dat=121642 ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel
Re: [Hibernate] Roadmap
1) Antlr query translator redesign. The original Antlr-based translator was a great first cut and showed us the usefulness of Antlr for this task; in many ways it ways a learning experience. Now, it is time to take those experiences and redesign how the translator works in a few areas and to add some significant enhancements. This will be the subject of a separate email a little later. This work is already well underway on a separate branch in SVN. This is probably out-of-the-question, but here it goes: Have you looked into if antlr3 could help us in anyway ? One thing I understood from their release notes is that they now have a clear distinction between generationtime and runtime resulting in a smaller footprint and easier isolation. 2) Adding the notion of a component persister. The goal here is to move most of the logic off of ComponentType to a persister managed by the session factory. The impetus being twofold: a) certain hibernate configuration parameters are currently considered global because of the way ComponentType currently works; the two most annoying being 'hibernate.bytecode.use_reflection_optimizer' and 'hibernate.bytecode.provider'. These changes would allow both of those settings to become session factory scoped values. b) general code cleanup and encapsulation; this aligns with how entities are managed by the EntityTypes. More about this in a later email also. Note that many pre-requisite changes for this have already been made on HEAD (i.e. the inclusion of the o.h.tuple.ComponentMetamodel). in context of wether this should go to 3.3 or 3.2 then a) could be a sentiment for 3.2.something ? 4) Criteria API enhancements: a) I'd like to get everything that is currently possible in HQL as a capability in Criteria queries. Ideally, I'd like to re-use some of the changes being made to the Antlr query translator to facilitate these enhancements. +1 for everything currently possible in HQL. b) statistics collection - the only real possibility I see here is to expose the ability to name criteria queries and expose the stats based on the given name. sounds fair enough. 5) Completion of the EntityMode and Tuplizer capabilities. This has been hanging around for a while now. There are a couple of specific things we need to finish off here: a) we know that recognizing the concrete type of polymorphic associations is completely broken when using the dom4j entity mode. This is because we currently do not require that node names be unique and we also do not require that the DOM node contain any type of discrimination value. Need to decide on the approach that allows this to work and that is hopefully non-invasive. b) allow user defined entity modes. The infrastructure for allowing this is now in place in HEAD. However, there are currently a lot of places in the code base that assume the entity modes are enums and do == type comparisions. We either need to change all those, or somehow make the user register their custom entity modes. Plus the DTD then needs to be updated to support this. all sounds good. Another thing to discuss is whether these should be bundled in the 3.2.x series, or to go with a 3.3.x. I personally vote to go with a 3.3.x series as 3.2.x was essentially targetting JPA-related work. If we agree for 3.3, then I'll branch HEAD off onto a 3.2 specific branch and we can start to use HEAD for 3.3 work. starting 3.3 sounds like a plan for the antlr changes and entitymode. /max Thoughts? - 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=lnkkid=120709bid=263057dat=121642 ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel -- -- Max Rydahl Andersen callto://max.rydahl.andersen Hibernate [EMAIL PROTECTED] http://hibernate.org JBoss Inc [EMAIL PROTECTED] - 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=lnkkid=120709bid=263057dat=121642 ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel
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=lnkkid=120709bid=263057dat=121642 ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel -- -- Max Rydahl Andersen callto://max.rydahl.andersen Hibernate [EMAIL PROTECTED] http://hibernate.org JBoss Inc [EMAIL PROTECTED] - 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=lnkkid=120709bid=263057dat=121642 ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel
Re: [Hibernate] Roadmap - components
Type is *NOT* a public API... -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=lnkkid=120709bid=263057dat=121642 ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel -- -- Max Rydahl Andersen callto://max.rydahl.andersen Hibernate [EMAIL PROTECTED] http://hibernate.org JBoss Inc [EMAIL PROTECTED] - 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=lnkkid=120709bid=263057dat=121642 ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel
Re: [Hibernate] Roadmap - components
On Mon, 17 Jul 2006 17:41:25 +0200, Steve Ebersole [EMAIL PROTECTED] 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=lnkkid=120709bid=263057dat=121642 ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel -- -- Max Rydahl Andersen callto://max.rydahl.andersen Hibernate [EMAIL PROTECTED] http://hibernate.org JBoss Inc [EMAIL PROTECTED] - 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=lnkkid=120709bid=263057dat=121642 ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel
Re: [Hibernate] Roadmap - components
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 [EMAIL PROTECTED] 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=lnkkid=120709bid=263057dat=121642 ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel -- -- Max Rydahl Andersen callto://max.rydahl.andersen Hibernate [EMAIL PROTECTED] http://hibernate.org JBoss Inc [EMAIL PROTECTED] - 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=lnkkid=120709bid=263057dat=121642 ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel
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 [EMAIL PROTECTED] 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=lnkkid=120709bid=263057dat=121642 ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel -- -- Max Rydahl Andersen callto://max.rydahl.andersen Hibernate [EMAIL PROTECTED] http://hibernate.org JBoss Inc [EMAIL PROTECTED] - 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=lnkkid=120709bid=263057dat=121642 ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel
Re: [Hibernate] Roadmap
Antlr3 is currently still beta. There are some very nice new features (like the tree construction rewrite rules). Not sure, we'll have to watch and see how it progresses. They also have an IDE for this series, btw ;) Well you say 3.3 is more appropriate for the antlr (#1) and tuplizer (#5) stuff, but the rest should be 3.2.x. But the Criteria stuff (#4) is dependant upon the antlr stuff. The cache provider changes I think are clearly inappropriate for a point release. So that just leaves a question about the component persisters. -Original Message- From: Max Andersen Sent: Monday, July 17, 2006 9:50 AM To: Steve Ebersole; Hibernate development Subject: Re: [Hibernate] Roadmap 1) Antlr query translator redesign. The original Antlr-based translator was a great first cut and showed us the usefulness of Antlr for this task; in many ways it ways a learning experience. Now, it is time to take those experiences and redesign how the translator works in a few areas and to add some significant enhancements. This will be the subject of a separate email a little later. This work is already well underway on a separate branch in SVN. This is probably out-of-the-question, but here it goes: Have you looked into if antlr3 could help us in anyway ? One thing I understood from their release notes is that they now have a clear distinction between generationtime and runtime resulting in a smaller footprint and easier isolation. 2) Adding the notion of a component persister. The goal here is to move most of the logic off of ComponentType to a persister managed by the session factory. The impetus being twofold: a) certain hibernate configuration parameters are currently considered global because of the way ComponentType currently works; the two most annoying being 'hibernate.bytecode.use_reflection_optimizer' and 'hibernate.bytecode.provider'. These changes would allow both of those settings to become session factory scoped values. b) general code cleanup and encapsulation; this aligns with how entities are managed by the EntityTypes. More about this in a later email also. Note that many pre-requisite changes for this have already been made on HEAD (i.e. the inclusion of the o.h.tuple.ComponentMetamodel). in context of wether this should go to 3.3 or 3.2 then a) could be a sentiment for 3.2.something ? 4) Criteria API enhancements: a) I'd like to get everything that is currently possible in HQL as a capability in Criteria queries. Ideally, I'd like to re-use some of the changes being made to the Antlr query translator to facilitate these enhancements. +1 for everything currently possible in HQL. b) statistics collection - the only real possibility I see here is to expose the ability to name criteria queries and expose the stats based on the given name. sounds fair enough. 5) Completion of the EntityMode and Tuplizer capabilities. This has been hanging around for a while now. There are a couple of specific things we need to finish off here: a) we know that recognizing the concrete type of polymorphic associations is completely broken when using the dom4j entity mode. This is because we currently do not require that node names be unique and we also do not require that the DOM node contain any type of discrimination value. Need to decide on the approach that allows this to work and that is hopefully non-invasive. b) allow user defined entity modes. The infrastructure for allowing this is now in place in HEAD. However, there are currently a lot of places in the code base that assume the entity modes are enums and do == type comparisions. We either need to change all those, or somehow make the user register their custom entity modes. Plus the DTD then needs to be updated to support this. all sounds good. Another thing to discuss is whether these should be bundled in the 3.2.x series, or to go with a 3.3.x. I personally vote to go with a 3.3.x series as 3.2.x was essentially targetting JPA-related work. If we agree for 3.3, then I'll branch HEAD off onto a 3.2 specific branch and we can start to use HEAD for 3.3 work. starting 3.3 sounds like a plan for the antlr changes and entitymode. /max Thoughts? - 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=lnkkid=120709bid=263057dat=121642 ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel -- -- Max Rydahl Andersen callto://max.rydahl.andersen Hibernate [EMAIL PROTECTED] http://hibernate.org JBoss Inc [EMAIL PROTECTED]
Re: [Hibernate] Roadmap
On Mon, 17 Jul 2006 17:58:53 +0200, Steve Ebersole [EMAIL PROTECTED] wrote: Antlr3 is currently still beta. There are some very nice new features (like the tree construction rewrite rules). Not sure, we'll have to watch and see how it progresses. They also have an IDE for this series, btw ;) Yes - and it actually looks very usefull ;) It would also remove the antlr class collision issues since noone uses it ;) (except of course Drools) Well you say 3.3 is more appropriate for the antlr (#1) and tuplizer (#5) stuff, but the rest should be 3.2.x. But the Criteria stuff (#4) is dependant upon the antlr stuff. The cache provider changes I think are clearly inappropriate for a point release. So that just leaves a question about the component persisters. a 2-phased migration as you talked about might be the way forward since the sf-level control of bytecode gen would be good (but i don't know if it is critical-critical?) -Original Message- From: Max Andersen Sent: Monday, July 17, 2006 9:50 AM To: Steve Ebersole; Hibernate development Subject: Re: [Hibernate] Roadmap 1) Antlr query translator redesign. The original Antlr-based translator was a great first cut and showed us the usefulness of Antlr for this task; in many ways it ways a learning experience. Now, it is time to take those experiences and redesign how the translator works in a few areas and to add some significant enhancements. This will be the subject of a separate email a little later. This work is already well underway on a separate branch in SVN. This is probably out-of-the-question, but here it goes: Have you looked into if antlr3 could help us in anyway ? One thing I understood from their release notes is that they now have a clear distinction between generationtime and runtime resulting in a smaller footprint and easier isolation. 2) Adding the notion of a component persister. The goal here is to move most of the logic off of ComponentType to a persister managed by the session factory. The impetus being twofold: a) certain hibernate configuration parameters are currently considered global because of the way ComponentType currently works; the two most annoying being 'hibernate.bytecode.use_reflection_optimizer' and 'hibernate.bytecode.provider'. These changes would allow both of those settings to become session factory scoped values. b) general code cleanup and encapsulation; this aligns with how entities are managed by the EntityTypes. More about this in a later email also. Note that many pre-requisite changes for this have already been made on HEAD (i.e. the inclusion of the o.h.tuple.ComponentMetamodel). in context of wether this should go to 3.3 or 3.2 then a) could be a sentiment for 3.2.something ? 4) Criteria API enhancements: a) I'd like to get everything that is currently possible in HQL as a capability in Criteria queries. Ideally, I'd like to re-use some of the changes being made to the Antlr query translator to facilitate these enhancements. +1 for everything currently possible in HQL. b) statistics collection - the only real possibility I see here is to expose the ability to name criteria queries and expose the stats based on the given name. sounds fair enough. 5) Completion of the EntityMode and Tuplizer capabilities. This has been hanging around for a while now. There are a couple of specific things we need to finish off here: a) we know that recognizing the concrete type of polymorphic associations is completely broken when using the dom4j entity mode. This is because we currently do not require that node names be unique and we also do not require that the DOM node contain any type of discrimination value. Need to decide on the approach that allows this to work and that is hopefully non-invasive. b) allow user defined entity modes. The infrastructure for allowing this is now in place in HEAD. However, there are currently a lot of places in the code base that assume the entity modes are enums and do == type comparisions. We either need to change all those, or somehow make the user register their custom entity modes. Plus the DTD then needs to be updated to support this. all sounds good. Another thing to discuss is whether these should be bundled in the 3.2.x series, or to go with a 3.3.x. I personally vote to go with a 3.3.x series as 3.2.x was essentially targetting JPA-related work. If we agree for 3.3, then I'll branch HEAD off onto a 3.2 specific branch and we can start to use HEAD for 3.3 work. starting 3.3 sounds like a plan for the antlr changes and entitymode. /max Thoughts? - 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
