Re: [hibernate-dev] Programmatic Mapping patch
On 26 nov. 09, at 09:32, Sanne Grinovero wrote: About 2) 2A - fullTextFilterDef: While it's ok for the annotation to stay on an indexed entity, I don't see a named filter as coupled/related to an entity, shouldn't this be part of global settings? Ah right, makes sense 2B - analyzerDiscriminator yes makes sense only on an indexed entity, not on indexedembeeded as it's being ignored on the embedded entity (currently.. improve? not to support in API now anyway) ok 2C - similarity We actually check for only one Similarity being set for a whole index (i.e. class hierarchy), so this is not settable on indexedembedded for sure. Actually it might make more sense on a index configuration, rather than on an entity configuration - if you accept a mismatch in how configuration works programmatic vs annotations. There's an open issue already to set similarity at index level (in addition to annotating the root type), we could consider programmatic already improved in this sense. 4 - Is date bridge exclusive to calendar bridge? I think the contract expresses that today. Don't know what you mean, but something is wrong here: we have a CalendarBridge and a DateBridge. Cheers, Sanne 2009/11/26 Emmanuel Bernard emman...@hibernate.org: Hey, Let's release Beta1 as it is except for 5 and 6 and take time to try the API before refining it. On 25 nov. 09, at 17:29, Amin Mohammed-Coleman wrote: Hi All, Would it be possible get feedback with regards to points 2, 3 and 4. I can create patch to address those issues. Cheers Amin On Fri, Nov 20, 2009 at 2:20 PM, Emmanuel Bernard ebern...@redhat.com wrote: Hi Amin, I've committed your patch, thanks! There is still some work and questions remaining but that's a big coverage improvement. Now on to the doc to get the release out :) Here is my raw feedback 1. Interface vs class? Should we start using interfaces instead of classes, at least for SearchMapping. That way we could hide the getEntityDescriptor() method to the users. I think we need to start using superclasses or super interfaces to enforce the repeated contracts down to the tree of navigation? 2. Should the methods be on IndexedMapping not EntityMapping? - fullTextFilterDef - analyzerDiscriminator - similarity Question to Hardy and Sanne, do these concepts make sense on a non @indexed element? I can't remember how the parser behaves. I think these methods should be onn IndexedMapping rather than EntityMapping - boost - providedId The problem with this approach is that we would need to differentiate PropertyMapping and IndexedPropertyMapping. I am not sure this additional complexity is worth the extra help to the developer. 3. property(String name, ElementType type) should it be replaced with specific methods like? .field() = conflict with lucene field .getter() 4. Is date bridge exclusive to calendar bridge? I think the contract expresses that today. 5. ContainedInMapping does not contain the necessary upper methods. 6. I've updated the original ProvidedIdTest, Can you push the same changes to the programmatic version of the test. ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Programmatic Mapping patch
Hi So I'll make the following changes 1) Move fulltextfilterdef to a global settings, similar to the Analyzer definitions. This means that SearchFactoryImpl would need to be updated to check for not only entities for filter defs but also in the global settings? 2) Remove analyzerDescriminator from indexEmbedded() 3) Create a SearchMappingFactory class which returns a SearchMapping implementation? 4) Make SearchMapping into an interface I can have these done and with you by the end of today or tomorrow mornign (I've got a job interview today...gulp) Cheers Amin On Thu, Nov 26, 2009 at 8:41 AM, Emmanuel Bernard emman...@hibernate.orgwrote: On 26 nov. 09, at 09:32, Sanne Grinovero wrote: About 2) 2A - fullTextFilterDef: While it's ok for the annotation to stay on an indexed entity, I don't see a named filter as coupled/related to an entity, shouldn't this be part of global settings? Ah right, makes sense 2B - analyzerDiscriminator yes makes sense only on an indexed entity, not on indexedembeeded as it's being ignored on the embedded entity (currently.. improve? not to support in API now anyway) ok 2C - similarity We actually check for only one Similarity being set for a whole index (i.e. class hierarchy), so this is not settable on indexedembedded for sure. Actually it might make more sense on a index configuration, rather than on an entity configuration - if you accept a mismatch in how configuration works programmatic vs annotations. There's an open issue already to set similarity at index level (in addition to annotating the root type), we could consider programmatic already improved in this sense. 4 - Is date bridge exclusive to calendar bridge? I think the contract expresses that today. Don't know what you mean, but something is wrong here: we have a CalendarBridge and a DateBridge. Cheers, Sanne 2009/11/26 Emmanuel Bernard emman...@hibernate.org: Hey, Let's release Beta1 as it is except for 5 and 6 and take time to try the API before refining it. On 25 nov. 09, at 17:29, Amin Mohammed-Coleman wrote: Hi All, Would it be possible get feedback with regards to points 2, 3 and 4. I can create patch to address those issues. Cheers Amin On Fri, Nov 20, 2009 at 2:20 PM, Emmanuel Bernard ebern...@redhat.com wrote: Hi Amin, I've committed your patch, thanks! There is still some work and questions remaining but that's a big coverage improvement. Now on to the doc to get the release out :) Here is my raw feedback 1. Interface vs class? Should we start using interfaces instead of classes, at least for SearchMapping. That way we could hide the getEntityDescriptor() method to the users. I think we need to start using superclasses or super interfaces to enforce the repeated contracts down to the tree of navigation? 2. Should the methods be on IndexedMapping not EntityMapping? - fullTextFilterDef - analyzerDiscriminator - similarity Question to Hardy and Sanne, do these concepts make sense on a non @indexed element? I can't remember how the parser behaves. I think these methods should be onn IndexedMapping rather than EntityMapping - boost - providedId The problem with this approach is that we would need to differentiate PropertyMapping and IndexedPropertyMapping. I am not sure this additional complexity is worth the extra help to the developer. 3. property(String name, ElementType type) should it be replaced with specific methods like? .field() = conflict with lucene field .getter() 4. Is date bridge exclusive to calendar bridge? I think the contract expresses that today. 5. ContainedInMapping does not contain the necessary upper methods. 6. I've updated the original ProvidedIdTest, Can you push the same changes to the programmatic version of the test. ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [infinispan-dev] Exposing transient/mortality information externally
FYI On 11/26/2009 10:16 AM, Galder Zamarreno wrote: Hi, Re: http://www.jboss.org/index.html?module=bbop=viewtopicp=4267469#4267469 I think Brian has a good point here. We don't expose any internal information wrt each cache entry's expiry/eviction values. Brian has a good point that this could guide him in finding out which entries have been last been used, how long they've been in memory and how it could tweak expiration/eviction accordingly. If we don't do anything, I think we run the risk of people being forced to get hold of the container, looping through it and getting information that they need from inspecting internal classes. So, I'd suggest that we add a JMX method to CacheDelegate called something like: MapString, MapString, long getTransientAndMortalityInformation(). (I'm open to suggestions to other names. This is the 1st thing that came to my mind) This would return a Map where the key is the toString form of the cache key and the value part is a map where individual transient/mortal properties are returned. I.e. [Person#1:[created:123456,lifespan:12,maxIdle:6,lasUsed:13456], Person#2:[created:234567,lifespan:12,maxIdle:6,lasUsed:24567], ...] We could event add calculated properties such as 'age' which is current - created. This would vary with each call obviously. As indicated in the forum entry, at least based on this use case, I don't see an immediate need to query this type of information given a key, although could be potentially useful for other use cases. The reason this would not help much right now is because it is Hibernate that creates the keys of 2nd level cache (i.e. CacheKey) and these are nor meant to be recreated externally, so it'd be hard for external apps to get something out of the Infinispan cache directly without going through the Hibernate integration layer. My suggested JMX method could allow for individual transient/mortality information to be queried by tools, or other client jmx code. Maybe some tools could use that to create a table or something like that which could be ordered based on a column? i.e. age. Also, tools or client jmx code could convert those longs into whatever they want: seconds, minutes...etc The reason I think JMX is a good candidate here is this is inherently monitoring information and it allows us to expose internal information via primitives without having to expose internal classes. Thoughts? Cheers, -- Galder Zamarreño Sr. Software Engineer Infinispan, JBoss Cache ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] Incompatibilites between hibernate-core 3.5.0-Beta-2 and hibernate-annotations 3.4.0GA
//Hi hiberante-developers, I don't understand exactly what the statement */Bundled with Hibernate Core as of 3.5.x /*/(see below/) means, but I'd like to point out that there are several* *incompatibilities between hiberante3.jar (3.5beta2) and hibernate-annotations.jar + hibernate-commons-annotations.jar (3.4.0GA). This because of overlapping classes with different signature (please see exceptions below) The environment with 3.5beta2 works correctly only if in the classpath hiberante3.jar preceeds the other 2 jars. Please ignore this post in case the problem is already known best regards G.D. /Snippet of?/ https://www.hibernate.org/6.html Hibernate Annotations 3.4.0 GA20.08.2008 Production / / */Bundled with Hibernate Core as of 3.5.x/* Classpath sequence:?? hibernate-annotations.jar:hibernate-commons-annotations.jar:hibernate3.jar [exec] [hibernatetool] Executing Hibernate Tool with a JPA Configuration [exec] [hibernatetool] 1. task: hbm2ddl (Generates database schema) [exec] [hibernatetool] SLF4J: This version of SLF4J requires log4j version 1.2.12 or later. See also http://www.slf4j.org/codes.html#log4j_version [exec] [hibernatetool] EMMA: collecting runtime coverage data ... [exec] [hibernatetool] An exception occurred while running exporter #2:hbm2ddl (Generates database schema) [exec] [hibernatetool] To get the full stack trace run ant with -verbose [exec] [hibernatetool] Problems in creating a configuration for JPA. Have you remembered to add hibernate EntityManager jars to the classpath ? [exec] [hibernatetool] java.lang.reflect.InvocationTargetException [exec] [hibernatetool] *java.lang.IncompatibleClassChangeError: class org.hibernate.cfg.ExtendedMappings has interface org.hibernate.cfg.Mappings as super class* Classpath sequence: hibernate-commons-annotations.jar:hibernate3.jar:hibernate-annotations.jar [exec] [hibernatetool] Executing Hibernate Tool with a JPA Configuration [exec] [hibernatetool] 1. task: hbm2ddl (Generates database schema) [exec] [hibernatetool] SLF4J: This version of SLF4J requires log4j version 1.2.12 or later. See also http://www.slf4j.org/codes.html#log4j_version [exec] [hibernatetool] An exception occurred while running exporter #2:hbm2ddl (Generates database schema) [exec] [hibernatetool] To get the full stack trace run ant with -verbose [exec] [hibernatetool] Problems in creating a configuration for JPA. Have you remembered to add hibernate EntityManager jars to the classpath ? [exec] [hibernatetool] java.lang.ExceptionInInitializerError [exec] [hibernatetool] *java.lang.ClassCastException: org.hibernate.annotations.common.reflection.java.JavaReflectionManager cannot be cast to org.hibernate.annotations.common.reflection.MetadataProviderInjector ** *Classpath sequence:? hibernate3.jar:hibernate-annotations.jar:hibernate-commons-annotations.jar ???hibernatetool* *hbm2ddl* OK* ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [infinispan-dev] Exposing transient/mortality information externally
On 26 Nov 2009, at 09:16, Galder Zamarreno wrote: Hi, Re: http://www.jboss.org/index.html?module=bbop=viewtopicp=4267469#4267469 I think Brian has a good point here. We don't expose any internal information wrt each cache entry's expiry/eviction values. Brian has a good point that this could guide him in finding out which entries have been last been used, how long they've been in memory and how it could tweak expiration/eviction accordingly. If we don't do anything, I think we run the risk of people being forced to get hold of the container, looping through it and getting information that they need from inspecting internal classes. So, I'd suggest that we add a JMX method to CacheDelegate called something like: MapString, MapString, long getTransientAndMortalityInformation(). (I'm open to suggestions to other names. This is the 1st thing that came to my mind) This would return a Map where the key is the toString form of the cache key and the value part is a map where individual transient/mortal properties are returned. I.e. [Person#1:[created:123456,lifespan:12,maxIdle:6,lasUsed:13456], Person#2:[created:234567,lifespan:12,maxIdle:6,lasUsed:24567], ...] We could event add calculated properties such as 'age' which is current - created. This would vary with each call obviously. Surely that would be hugely expensive? To iterate through the entire collection? And what when you have JOPR polling this value every 5 seconds or something? ;) As indicated in the forum entry, at least based on this use case, I don't see an immediate need to query this type of information given a key, although could be potentially useful for other use cases. The reason this would not help much right now is because it is Hibernate that creates the keys of 2nd level cache (i.e. CacheKey) and these are nor meant to be recreated externally, so it'd be hard for external apps to get something out of the Infinispan cache directly without going through the Hibernate integration layer. My suggested JMX method could allow for individual transient/mortality information to be queried by tools, or other client jmx code. Maybe some tools could use that to create a table or something like that which could be ordered based on a column? i.e. age. Also, tools or client jmx code could convert those longs into whatever they want: seconds, minutes...etc The reason I think JMX is a good candidate here is this is inherently monitoring information and it allows us to expose internal information via primitives without having to expose internal classes. Thoughts? Cheers, -- Galder Zamarreño Sr. Software Engineer Infinispan, JBoss Cache ___ infinispan-dev mailing list infinispan-...@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Manik Surtani ma...@jboss.org Lead, Infinispan Lead, JBoss Cache http://www.infinispan.org http://www.jbosscache.org ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Programmatic Mapping patch
On 26 nov. 09, at 10:59, Amin Mohammed-Coleman wrote: Hi So I'll make the following changes 1) Move fulltextfilterdef to a global settings, similar to the Analyzer definitions. This means that SearchFactoryImpl would need to be updated to check for not only entities for filter defs but also in the global settings? ok 2) Remove analyzerDescriminator from indexEmbedded() ok 3) Create a SearchMappingFactory class which returns a SearchMapping implementation? no not yet, we are not mature. 4) Make SearchMapping into an interface see above I can have these done and with you by the end of today or tomorrow mornign (I've got a job interview today...gulp) Cheers Amin On Thu, Nov 26, 2009 at 8:41 AM, Emmanuel Bernard emman...@hibernate.org wrote: On 26 nov. 09, at 09:32, Sanne Grinovero wrote: About 2) 2A - fullTextFilterDef: While it's ok for the annotation to stay on an indexed entity, I don't see a named filter as coupled/related to an entity, shouldn't this be part of global settings? Ah right, makes sense 2B - analyzerDiscriminator yes makes sense only on an indexed entity, not on indexedembeeded as it's being ignored on the embedded entity (currently.. improve? not to support in API now anyway) ok 2C - similarity We actually check for only one Similarity being set for a whole index (i.e. class hierarchy), so this is not settable on indexedembedded for sure. Actually it might make more sense on a index configuration, rather than on an entity configuration - if you accept a mismatch in how configuration works programmatic vs annotations. There's an open issue already to set similarity at index level (in addition to annotating the root type), we could consider programmatic already improved in this sense. 4 - Is date bridge exclusive to calendar bridge? I think the contract expresses that today. Don't know what you mean, but something is wrong here: we have a CalendarBridge and a DateBridge. Cheers, Sanne 2009/11/26 Emmanuel Bernard emman...@hibernate.org: Hey, Let's release Beta1 as it is except for 5 and 6 and take time to try the API before refining it. On 25 nov. 09, at 17:29, Amin Mohammed-Coleman wrote: Hi All, Would it be possible get feedback with regards to points 2, 3 and 4. I can create patch to address those issues. Cheers Amin On Fri, Nov 20, 2009 at 2:20 PM, Emmanuel Bernard ebern...@redhat.com wrote: Hi Amin, I've committed your patch, thanks! There is still some work and questions remaining but that's a big coverage improvement. Now on to the doc to get the release out :) Here is my raw feedback 1. Interface vs class? Should we start using interfaces instead of classes, at least for SearchMapping. That way we could hide the getEntityDescriptor() method to the users. I think we need to start using superclasses or super interfaces to enforce the repeated contracts down to the tree of navigation? 2. Should the methods be on IndexedMapping not EntityMapping? - fullTextFilterDef - analyzerDiscriminator - similarity Question to Hardy and Sanne, do these concepts make sense on a non @indexed element? I can't remember how the parser behaves. I think these methods should be onn IndexedMapping rather than EntityMapping - boost - providedId The problem with this approach is that we would need to differentiate PropertyMapping and IndexedPropertyMapping. I am not sure this additional complexity is worth the extra help to the developer. 3. property(String name, ElementType type) should it be replaced with specific methods like? .field() = conflict with lucene field .getter() 4. Is date bridge exclusive to calendar bridge? I think the contract expresses that today. 5. ContainedInMapping does not contain the necessary upper methods. 6. I've updated the original ProvidedIdTest, Can you push the same changes to the programmatic version of the test. ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] join this list
Hello All. ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] For subscribe
-- Thanks Brajesh Patel HotWax Media http://www.hotwaxmedia.com ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
