From hardy at hibernate.org Mon Dec 1 06:07:54 2014 From: hardy at hibernate.org (Hardy Ferentschik) Date: Mon, 1 Dec 2014 12:07:54 +0100 Subject: [hibernate-dev] Maintenance of github hooks for Hibernate ORM In-Reply-To: References: Message-ID: <20141201110754.GA18070@Sarmakand-4.local> Hi, On Mon, Dec 01, 2014 at 12:01:39AM +0000, Sanne Grinovero wrote: > Hi Steve, > I was checking our web-hooks and various integrations, noticed two > thing with the hooks setup for ORM: > > # bitbucket > > The hook wasn't working as github refused to deliver the metadata as > the SSL certificate would fail, as the hook was setup to use the old > URL "hibernate.onjira.com" rather than "hibernate.atlassian.net". > > I've replaced the notification from > https://hibernate.onjira.com/rest/bitbucket/1.0/repository/28/sync > to > https://hibernate.atlassian.net/rest/bitbucket/1.0/repository/28/sync > and it seems it accepts it now. > > I don't know however what the purpose of this hook is, so I hope > having fixed this doesn't cause any trouble. > Also it seems other projects have a similar hook, but use a different number? My guess is that this hook was used for the earlier versions of the GitHub to Jira integration. I don't think it is needed anymore, but let's wait what Steve says. > For example hibernate-metamodelgen has: > https://hibernate.onjira.com/rest/bitbucket/1.0/repository/34/sync > Should I update all domain names keeping the number as-is? The metamodelgen hook can for sure be removed. After all the code has been merged into the ORM code base. --Hardy -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 496 bytes Desc: not available Url : http://lists.jboss.org/pipermail/hibernate-dev/attachments/20141201/ca3143dc/attachment.bin From davide at hibernate.org Mon Dec 1 07:34:51 2014 From: davide at hibernate.org (Davide D'Alto) Date: Mon, 1 Dec 2014 12:34:51 +0000 Subject: [hibernate-dev] Maintenance on ci.hibernate.org In-Reply-To: References: Message-ID: On a related note, I've also reinstalled couchdb since it stopped working for some reason. I've also changed the maven version used for hibernate-ogm-master-jdk9 to maven 3.2.3. Maven 3.2.3 fixes some some bugs related to the profiles activation. Davide On Sun, Nov 30, 2014 at 10:22 PM, Sanne Grinovero wrote: > All, > we needed to do some unplanned maintenance on ci.hibernate.org. > > At some point it was clear that we needed do deploy some significant > upgrades so while Davide fixed Apache HTTPD, I went ahead and updated > all of Jenkins plugins as well.. which I usually avoid to not need > checking all builds and integrations with external services, but this > time all validations would be needed anyway. > > So: > - I'm sorry if you received some false notifications from it. > - If some builds are now broken, it might need some reconfiguration. > - same for plugins configurations: I'm unable to double-check all > things you've all setup. > > Please let me know what isn't working anymore, or if you have a moment > to volunteer looking yourself that would be great. > > # Reminder > Anyone in the Hibernate organization on GitHub has configuration and > write permissions on this server; if you know what you're doing feel > free to take advantage of that but please always share a summary of > what you did / plan to do. > > Sanne > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From steve at hibernate.org Mon Dec 1 11:45:24 2014 From: steve at hibernate.org (Steve Ebersole) Date: Mon, 1 Dec 2014 10:45:24 -0600 Subject: [hibernate-dev] Maintenance of github hooks for Hibernate ORM In-Reply-To: References: Message-ID: On Sun, Nov 30, 2014 at 6:01 PM, Sanne Grinovero wrote: > Hi Steve, > I was checking our web-hooks and various integrations, noticed two > thing with the hooks setup for ORM: > > # bitbucket > To be honest, I do not know if the new Jira "Development Tools - GitHub" integration needs these GitHub-side web hooks anymore. I know it did initially, but I think they moved to more of a REST/pull approach in more recent versions. > # Post-Bin log > I knew postbin service had gone away, but actually had not known of this replacement. The trouble with this is that we have to capture every push. I don't know if there is a limit on this service as to how much data it will keep for each bin, but every push to each of our repos is a lot of JSON data, Do y'all feel we still need this "forced push" tattle-taling? From steve at hibernate.org Mon Dec 1 12:02:03 2014 From: steve at hibernate.org (Steve Ebersole) Date: Mon, 1 Dec 2014 11:02:03 -0600 Subject: [hibernate-dev] Closed pull requests In-Reply-To: References: <84D5AADC-23D4-4377-AED7-1EB88869FF30@gmx.net> <7B4B4720-5C93-43C7-BDD8-F515CAA1A4F6@gmx.net> Message-ID: They should get moved to the 4.3-based master. I think I found the relevant issues: * Oracle12cDialect - https://hibernate.atlassian.net/browse/HHH-9044 * PostgreSQL92Dialect & PostgreSQL94Dialect - https://hibernate.atlassian.net/browse/HHH-9167 I have reopened them and targeted them for 5.0 On Thu, Nov 27, 2014 at 2:41 PM, Andrej Golovnin wrote: > Hi Steve, > > > > https://github.com/hibernate/hibernate-orm/pull/777 > > > > > > > > > > Overall, checking that the PR still applies is a good idea too. > > while working on a new pull request for the issue HHH-9324 > I have noticed that the new master misses some dialects: > > Oracle12cDialect > PostgreSQL92Dialect > PostgreSQL94Dialect > > Are you going to restore this dialects from the old master > or should I add them back with the new pull request? > > Best regards, > Andrej Golovnin > From steve at hibernate.org Mon Dec 1 12:25:25 2014 From: steve at hibernate.org (Steve Ebersole) Date: Mon, 1 Dec 2014 11:25:25 -0600 Subject: [hibernate-dev] Making it pluggable how GenerationType.AUTO is mapped In-Reply-To: References: Message-ID: Maybe. I'll have to look a little closer. Is this something you are looking at for use with ORM 5.0? On Fri, Nov 28, 2014 at 5:08 AM, Gunnar Morling wrote: > Hi Steve, all, > > For OGM it would be beneficial if there was an extension point in ORM which > allows us to customize how GenerationType.AUTO is mapped. AFAICS, that's > currently semi-hard coded in ORM. Depending on whether > "new_generator_mappings" is set, either SEQUENCE (true) or "native" (false) > will be used. > > Now for the MongoDB grid dialect we'd ideally do the following: If the id > of an entity is declared as > > org.bson.typesObjectId > > or > > @Type(type = "objectid") String > > then map AUTO to IDENTITY (ObjectId is a MongoDB-specific type which > resembles an identity column). Otherwise map it to TABLE (or SEQUENCE, > which transparently falls back to TABLE). > > I.e. this decision would not be a global one, but depend on the specific id > type. > > Would this be feasible to do? or is it mandated by JPA somehow that AUTO is > always mapped in the same way? I cannot judge on the amount of changes > required in ORM as atm. AUTO always is mapped in the same way, it doesn't > depend on the specific entity and its id type. > > Any thoughts? > > Thanks, > > --Gunnar > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From steve at hibernate.org Mon Dec 1 12:28:21 2014 From: steve at hibernate.org (Steve Ebersole) Date: Mon, 1 Dec 2014 11:28:21 -0600 Subject: [hibernate-dev] org.hibernate.persister.spi.PersisterFactory and 5.0 In-Reply-To: References: Message-ID: As for the "parameter object", I came up with a decent (imo) solution. So I only wrap the things that are "contextual". Here is the contract right now: public interface PersisterFactory extends Service { /** * "Parameter object" providing access to additional information that may be needed * in the creation of the persisters. */ public static interface PersisterCreationContext { SessionFactoryImplementor getSessionFactory(); Metadata getMetadata(); } /** * Create an entity persister instance. * * @param entityBinding The mapping information describing the entity * @param entityCacheAccessStrategy The cache access strategy for the entity region * @param naturalIdCacheAccessStrategy The cache access strategy for the entity's natural-id cross-ref region * @param creationContext Access to additional information needed to create an EntityPersister * * @return An appropriate entity persister instance. * * @throws HibernateException Indicates a problem building the persister. */ public EntityPersister createEntityPersister( PersistentClass entityBinding, EntityRegionAccessStrategy entityCacheAccessStrategy, NaturalIdRegionAccessStrategy naturalIdCacheAccessStrategy, PersisterCreationContext creationContext) throws HibernateException; /** * Create a collection persister instance. * * @param collectionBinding The mapping information describing the collection * @param cacheAccessStrategy The cache access strategy for the collection region * @param creationContext Access to additional information needed to create an EntityPersister * * @return An appropriate collection persister instance. * * @throws HibernateException Indicates a problem building the persister. */ public CollectionPersister createCollectionPersister( Collection collectionBinding, CollectionRegionAccessStrategy cacheAccessStrategy, PersisterCreationContext creationContext) throws HibernateException; } PersisterCreationContext is the contextual info. And it can be "statically" defined for each and every call into PersisterFactory. The other params to #createEntityPersister and #createCollectionPersister are specific to that call. On Thu, Nov 27, 2014 at 10:35 AM, Steve Ebersole wrote: > Actually, I take that back about Metadata extending org.hibernate.cfg.Mappings. > I had contemplated doing that, but decided against it since Mappings > exposes all kinds of "extra" stuff that isn't actually mappings/metadata > (config info, contextual info, etc) and I did not want to fuglify these new > contracts that way. > > On Thu, Nov 27, 2014 at 10:25 AM, Steve Ebersole > wrote: > >> Well naturally there is still access to all this information :) >> >> IMO SessionFactoryObserver is a hack way of doing this. With 5.0, the >> way to do this would be one of the various bootstrap hooks I mentioned >> earlier. Specifically you want a hook that is called just after all >> metadata is fully known. >> >> BTW, for 5.0 the "metadata" is still using the mappings as defined in the >> org.hibernate.mapping package. So all that code fragment will continue to >> work aside from actually using the Configuration. Interestingly, had >> you used org.hibernate.cfg.Mappings#iterateTables rather than Configuration#getTableMappings(), >> this code would have continued to work with no changes at all. This is the >> point I made in the initial email about Metadata also being a >> org.hibernate.cfg.Mappings. >> >> >> On Thu, Nov 27, 2014 at 4:36 AM, Emmanuel Bernard > > wrote: >> >>> To add on Gunnar?s needs >>> >>> 3. Use Configuration to extract physical Table structure >>> >>> We also use configuration in the SchemaDefiner >>> The SchemaDefiner received the Configuration from a custom >>> implementation of SessionFactoryObserver and use it during >>> sessionFactoryCreated. >>> >>> The reason we use Configuration is so that this SchemaDefiner contract >>> can: >>> >>> - access to specific properties (say hibernate.0gm.neo4j.index >>> create-drop ) >>> - get information about the table, it?s unique constraints as shown in >>> this pseudo example >>> >>> Iterator tableMappings = configuration.getTableMappings(); >>> while ( tableMappings.hasNext() ) { >>> Table table = tableMappings.next(); >>> if ( table.isPhysicalTable() ) { >>> Label label = label( table.getName() ); >>> PrimaryKey primaryKey = table.getPrimaryKey(); >>> createConstraint( neo4jDb, table, label, primaryKey ); >>> @SuppressWarnings("unchecked") >>> Iterator columnIterator = table.getColumnIterator(); >>> while ( columnIterator.hasNext() ) { >>> Column column = columnIterator.next(); >>> if ( column.isUnique() ) { >>> createUniqueConstraintIfMissing( neo4jDb, label, >>> column.getName() ); >>> } >>> } >>> Iterator uniqueKeyIterator = >>> table.getUniqueKeyIterator(); >>> while ( uniqueKeyIterator.hasNext() ) { >>> createConstraint( neo4jDb, table, label, >>> uniqueKeyIterator.next() ); >>> } >>> } >>> } >>> >>> >>> >>> >>> On 27 Nov 2014, at 10:13, Gunnar Morling wrote: >>> >>> Hi, >>> >>> 2014-11-27 1:23 GMT+01:00 Steve Ebersole : >>> >>> Part of the goals for ORM 5.0 is moving from Configuration to the >>> ServiceRegistry+Metadata for building a SessionFactory. >>> >>> One of the points I ran into that will have to change >>> is org.hibernate.persister.spi.PersisterFactory. The problems is that >>> PersisterFactory accepts a Configuration as part of building >>> CollectionPersisters. The need for Configuration in the standard >>> CollectionPersister impls is amazingly trivial; we literally use it to >>> locate the associated entity's PersistentClass to grab the classes dom4j >>> node name, and this is right after we have just resolved the >>> corresponding >>> EntityPersister. The point being that the standard CollectionPersisters >>> really don't need access to the Configuration. >>> >>> I am pretty sure OGM provides a custom PersisterFactory, or is it just >>> the PersisterClassResolver that OGM provides? Also, I would assume OGM >>> is >>> providing custom CollectionPersister impls. This change would affect >>> both >>> usages. >>> >>> >>> We don't have a custom PersisterFactory, but there are >>> OgmPersisterClassResolver [1] and OgmCollectionPersister [2]. In the >>> latter >>> we accept a Configuration in the constructor but just pass it to the >>> super >>> 'ctor (AbstractCollectionPersister). We don't do anything ourselves with >>> it. >>> >>> >>> I wanted y'all to be aware of this upcoming change. But I also wanted to >>> start a discussion about what the signature(s) should become. Currently >>> we >>> pass: >>> >>> * Configuration >>> * Collection (the parsed mapping info) >>> * CollectionRegionAccessStrategy >>> * SessionFactoryImplementor >>> >>> >>> I suggest we pass: >>> >>> * Collection >>> * CollectionRegionAccessStrategy >>> * SessionFactoryImplementor >>> * Mapping >>> >>> >>> Should be fine for OGM. I suggest to wrap it into a parameter object >>> ("PersisterInitializationContext" or so). That way stuff can be added >>> down >>> the road without the need to instantly adapt existing persisters. >>> >>> (I changed order to align with the order for building EntityPersisters) >>> >>> >>> Mapping is org.hibernate.engine.spi.Mapping which is part of >>> Configuration. I decided to (at least temporarily) port this contract >>> forward to ease migration. Metadata implements it. >>> >>> There is a similar discussion to be had wrt Integrators. I will follow >>> up >>> with an email specific to them later. >>> >>> >>> Regarding the removal of Configuration in general, there will be some >>> more >>> work to be done in OGM. We have a custom sub-class, OgmConfiguration [3], >>> which is used for two purposes: >>> >>> 1) Set some properties automatically (to enable OGM's naming strategy and >>> query translator etc., use a specific mass indexer for Hibernate Search) >>> 2) Provide an entry point into the API for setting store specific >>> options, >>> e.g. like so: >>> >>> OgmConfiguration ogmCfg = ...; >>> ogmCfg.configureOptionsFor( MongoDB.class ) >>> .entity( GolfPlayer.class ) >>> .writeConcern( WriteConcernType.REPLICA_ACKNOWLEDGED ); >>> >>> We'll need a way to still do 1). >>> >>> 2) is not really required. We provide an alternative anyways, for cases >>> where you don't bootstrap OGM yourself. You can specify a callback class >>> via configuration properties, which then will be invoked and provides the >>> entry point to the fluent API. >>> >>> --Gunnar >>> >>> [1] >>> >>> https://github.com/hibernate/hibernate-ogm/blob/master/core/src/main/java/org/hibernate/ogm/jpa/impl/OgmPersisterClassResolver.java >>> [2] >>> >>> https://github.com/hibernate/hibernate-ogm/blob/master/core/src/main/java/org/hibernate/ogm/persister/impl/OgmCollectionPersister.java >>> [3] >>> >>> https://github.com/hibernate/hibernate-ogm/blob/master/core/src/main/java/org/hibernate/ogm/cfg/OgmConfiguration.java >>> >>> >>> >>> _______________________________________________ >>> hibernate-dev mailing list >>> hibernate-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> >>> _______________________________________________ >>> hibernate-dev mailing list >>> hibernate-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> >>> >>> >> > From steve at hibernate.org Mon Dec 1 15:22:44 2014 From: steve at hibernate.org (Steve Ebersole) Date: Mon, 1 Dec 2014 14:22:44 -0600 Subject: [hibernate-dev] org.hibernate.persister.spi.PersisterFactory and 5.0 In-Reply-To: References: Message-ID: Wanted to point out that I carried those signatures on to the persister ctors as well. In Amsterdam we had talked about OGM needing a bootstrap hook for the point just after all persisters have been built. Exactly what information did that hook need access to? On Mon, Dec 1, 2014 at 11:28 AM, Steve Ebersole wrote: > As for the "parameter object", I came up with a decent (imo) solution. So > I only wrap the things that are "contextual". Here is the contract right > now: > > > public interface PersisterFactory extends Service { > /** > * "Parameter object" providing access to additional information that may > be needed > * in the creation of the persisters. > */ > public static interface PersisterCreationContext { > SessionFactoryImplementor getSessionFactory(); > Metadata getMetadata(); > } > > /** > * Create an entity persister instance. > * > * @param entityBinding The mapping information describing the entity > * @param entityCacheAccessStrategy The cache access strategy for the > entity region > * @param naturalIdCacheAccessStrategy The cache access strategy for the > entity's natural-id cross-ref region > * @param creationContext Access to additional information needed to > create an EntityPersister > * > * @return An appropriate entity persister instance. > * > * @throws HibernateException Indicates a problem building the persister. > */ > public EntityPersister createEntityPersister( > PersistentClass entityBinding, > EntityRegionAccessStrategy entityCacheAccessStrategy, > NaturalIdRegionAccessStrategy naturalIdCacheAccessStrategy, > PersisterCreationContext creationContext) throws HibernateException; > > /** > * Create a collection persister instance. > * > * @param collectionBinding The mapping information describing the > collection > * @param cacheAccessStrategy The cache access strategy for the collection > region > * @param creationContext Access to additional information needed to > create an EntityPersister > * > * @return An appropriate collection persister instance. > * > * @throws HibernateException Indicates a problem building the persister. > */ > public CollectionPersister createCollectionPersister( > Collection collectionBinding, > CollectionRegionAccessStrategy cacheAccessStrategy, > PersisterCreationContext creationContext) throws HibernateException; > > } > > PersisterCreationContext is the contextual info. And it can be > "statically" defined for each and every call into PersisterFactory. The > other params to #createEntityPersister and #createCollectionPersister are > specific to that call. > > > On Thu, Nov 27, 2014 at 10:35 AM, Steve Ebersole > wrote: > >> Actually, I take that back about Metadata extending org.hibernate.cfg.Mappings. >> I had contemplated doing that, but decided against it since Mappings >> exposes all kinds of "extra" stuff that isn't actually mappings/metadata >> (config info, contextual info, etc) and I did not want to fuglify these new >> contracts that way. >> >> On Thu, Nov 27, 2014 at 10:25 AM, Steve Ebersole >> wrote: >> >>> Well naturally there is still access to all this information :) >>> >>> IMO SessionFactoryObserver is a hack way of doing this. With 5.0, the >>> way to do this would be one of the various bootstrap hooks I mentioned >>> earlier. Specifically you want a hook that is called just after all >>> metadata is fully known. >>> >>> BTW, for 5.0 the "metadata" is still using the mappings as defined in >>> the org.hibernate.mapping package. So all that code fragment will continue >>> to work aside from actually using the Configuration. Interestingly, >>> had you used org.hibernate.cfg.Mappings#iterateTables rather than >>> Configuration#getTableMappings(), this code would have continued to >>> work with no changes at all. This is the point I made in the initial email >>> about Metadata also being a org.hibernate.cfg.Mappings. >>> >>> >>> On Thu, Nov 27, 2014 at 4:36 AM, Emmanuel Bernard < >>> emmanuel at hibernate.org> wrote: >>> >>>> To add on Gunnar?s needs >>>> >>>> 3. Use Configuration to extract physical Table structure >>>> >>>> We also use configuration in the SchemaDefiner >>>> The SchemaDefiner received the Configuration from a custom >>>> implementation of SessionFactoryObserver and use it during >>>> sessionFactoryCreated. >>>> >>>> The reason we use Configuration is so that this SchemaDefiner contract >>>> can: >>>> >>>> - access to specific properties (say hibernate.0gm.neo4j.index >>>> create-drop ) >>>> - get information about the table, it?s unique constraints as shown in >>>> this pseudo example >>>> >>>> Iterator
tableMappings = configuration.getTableMappings(); >>>> while ( tableMappings.hasNext() ) { >>>> Table table = tableMappings.next(); >>>> if ( table.isPhysicalTable() ) { >>>> Label label = label( table.getName() ); >>>> PrimaryKey primaryKey = table.getPrimaryKey(); >>>> createConstraint( neo4jDb, table, label, primaryKey ); >>>> @SuppressWarnings("unchecked") >>>> Iterator columnIterator = table.getColumnIterator(); >>>> while ( columnIterator.hasNext() ) { >>>> Column column = columnIterator.next(); >>>> if ( column.isUnique() ) { >>>> createUniqueConstraintIfMissing( neo4jDb, label, >>>> column.getName() ); >>>> } >>>> } >>>> Iterator uniqueKeyIterator = >>>> table.getUniqueKeyIterator(); >>>> while ( uniqueKeyIterator.hasNext() ) { >>>> createConstraint( neo4jDb, table, label, >>>> uniqueKeyIterator.next() ); >>>> } >>>> } >>>> } >>>> >>>> >>>> >>>> >>>> On 27 Nov 2014, at 10:13, Gunnar Morling wrote: >>>> >>>> Hi, >>>> >>>> 2014-11-27 1:23 GMT+01:00 Steve Ebersole : >>>> >>>> Part of the goals for ORM 5.0 is moving from Configuration to the >>>> ServiceRegistry+Metadata for building a SessionFactory. >>>> >>>> One of the points I ran into that will have to change >>>> is org.hibernate.persister.spi.PersisterFactory. The problems is that >>>> PersisterFactory accepts a Configuration as part of building >>>> CollectionPersisters. The need for Configuration in the standard >>>> CollectionPersister impls is amazingly trivial; we literally use it to >>>> locate the associated entity's PersistentClass to grab the classes dom4j >>>> node name, and this is right after we have just resolved the >>>> corresponding >>>> EntityPersister. The point being that the standard CollectionPersisters >>>> really don't need access to the Configuration. >>>> >>>> I am pretty sure OGM provides a custom PersisterFactory, or is it just >>>> the PersisterClassResolver that OGM provides? Also, I would assume OGM >>>> is >>>> providing custom CollectionPersister impls. This change would affect >>>> both >>>> usages. >>>> >>>> >>>> We don't have a custom PersisterFactory, but there are >>>> OgmPersisterClassResolver [1] and OgmCollectionPersister [2]. In the >>>> latter >>>> we accept a Configuration in the constructor but just pass it to the >>>> super >>>> 'ctor (AbstractCollectionPersister). We don't do anything ourselves >>>> with it. >>>> >>>> >>>> I wanted y'all to be aware of this upcoming change. But I also wanted >>>> to >>>> start a discussion about what the signature(s) should become. >>>> Currently we >>>> pass: >>>> >>>> * Configuration >>>> * Collection (the parsed mapping info) >>>> * CollectionRegionAccessStrategy >>>> * SessionFactoryImplementor >>>> >>>> >>>> I suggest we pass: >>>> >>>> * Collection >>>> * CollectionRegionAccessStrategy >>>> * SessionFactoryImplementor >>>> * Mapping >>>> >>>> >>>> Should be fine for OGM. I suggest to wrap it into a parameter object >>>> ("PersisterInitializationContext" or so). That way stuff can be added >>>> down >>>> the road without the need to instantly adapt existing persisters. >>>> >>>> (I changed order to align with the order for building EntityPersisters) >>>> >>>> >>>> Mapping is org.hibernate.engine.spi.Mapping which is part of >>>> Configuration. I decided to (at least temporarily) port this contract >>>> forward to ease migration. Metadata implements it. >>>> >>>> There is a similar discussion to be had wrt Integrators. I will follow >>>> up >>>> with an email specific to them later. >>>> >>>> >>>> Regarding the removal of Configuration in general, there will be some >>>> more >>>> work to be done in OGM. We have a custom sub-class, OgmConfiguration >>>> [3], >>>> which is used for two purposes: >>>> >>>> 1) Set some properties automatically (to enable OGM's naming strategy >>>> and >>>> query translator etc., use a specific mass indexer for Hibernate Search) >>>> 2) Provide an entry point into the API for setting store specific >>>> options, >>>> e.g. like so: >>>> >>>> OgmConfiguration ogmCfg = ...; >>>> ogmCfg.configureOptionsFor( MongoDB.class ) >>>> .entity( GolfPlayer.class ) >>>> .writeConcern( WriteConcernType.REPLICA_ACKNOWLEDGED ); >>>> >>>> We'll need a way to still do 1). >>>> >>>> 2) is not really required. We provide an alternative anyways, for cases >>>> where you don't bootstrap OGM yourself. You can specify a callback class >>>> via configuration properties, which then will be invoked and provides >>>> the >>>> entry point to the fluent API. >>>> >>>> --Gunnar >>>> >>>> [1] >>>> >>>> https://github.com/hibernate/hibernate-ogm/blob/master/core/src/main/java/org/hibernate/ogm/jpa/impl/OgmPersisterClassResolver.java >>>> [2] >>>> >>>> https://github.com/hibernate/hibernate-ogm/blob/master/core/src/main/java/org/hibernate/ogm/persister/impl/OgmCollectionPersister.java >>>> [3] >>>> >>>> https://github.com/hibernate/hibernate-ogm/blob/master/core/src/main/java/org/hibernate/ogm/cfg/OgmConfiguration.java >>>> >>>> >>>> >>>> _______________________________________________ >>>> hibernate-dev mailing list >>>> hibernate-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>> >>>> _______________________________________________ >>>> hibernate-dev mailing list >>>> hibernate-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>> >>>> >>>> >>> >> > From hardy at hibernate.org Mon Dec 1 15:24:23 2014 From: hardy at hibernate.org (Hardy Ferentschik) Date: Mon, 1 Dec 2014 21:24:23 +0100 Subject: [hibernate-dev] Jandex 2.0 Beta - Java 8 Type Annotations, Generics, & Offline Reflection Message-ID: <20141201202423.GC20433@Sarmakand-4.lan> Hi, I think this email of Jason is worth forwarding to hibernate-dev. Jandex 2 sounds really interesting for all Hibernate projects. To a certain degree Jandex offers now a lot of the things Steve tried to do with the reflight stuff. I am not sure whether Jandex can completely replace it, but t can be for sure of help. Especially interesting to me is the fully resolved type information. In Search we have been talking for a long time to get rid of Commons Annotations. It is basically already possible now (using Jandex 1), but it got pushed back so far. Now with Jandex 2 we definitely should make the switch. Maybe Search 5.1? Last but not least Validator, there we have been talking about Jandex for a while as well. The new version would not have the benefit of being able to remove the dependency to classmate. I think we should have a look at this Beta and provide feedback to Jason if we find any problems. I am for sure to have a look at it in the context of Validator. --Hardy ----- Forwarded message from Jason Greene ----- I normally don?t spam you guys with Beta announcements, but since many of you are using Jandex, and this release has significant changes, in particular additional APIs, I wanted to make sure there was an opportunity for feedback before going final. For those unfamiliar with Jandex, it was originally created as an efficient bytecode based annotation indexer for AS7, but over time has evolved to also act as a reflection library that does not require class-loading nor complete linkage (you can analyze partial class graphs). For those interested in playing with runtime Java 8 Type annotations, which will likely end up in EE8 APIs, this release will likely be quite useful to you, since standard Java reflection does not currently expose this data. A brief guide for using Jandex is located here: https://github.com/wildfly/jandex Full notes are below. Thanks! Jandex 2.0 ????? - Binary and Source Compatibility All previous code *using* Jandex 1.1 should compile and run against 2.0. However, any code that extended ?closed" contracts (e.g. AnnotationTarget) will require updating. - Offline reflective APIs and improvements All methods and fields, whether annotated or not are all accessible, and supporting APIs were created to enable access to the information. Generics information is provided in a familiar pattern similar to Java reflection but with usability improvements. Type information is fully resolved. Method and field access now supports binary searchable. Annotations are categorized and filtered at various levels. All need to cast has been eliminated from the framework. - Implemented offline index persistence The format is radically different to support the storage of generics, type annotations, and the aggressive interning used to reduce memory usage. Monster deployment (713MB of class data) only requires 26MB of storage. JDK, which has 128MB of class data is requires only 4.8 MB. Compressing the indexes by including them in a jar reduces the capacity even further to about 14MB and 2.6 MB respectively. Loading time is extremely efficient, at 1 second to load the 26MB index for the monster deployment. A portability layer is provided to convert the pervious offline index formats into the new internal model. - Full Java 8 type annotation support Java 8 type annotations all you to use annotations almost anywhere. For example, the following is now allowed: @A Map<@B Comparable<@F Object @C [] @D [] @E []>, @G List <@H D>> b; @H O1. at E O2<@F S, @G T>. at D O3. at A Nested<@B U, @C V> bar6; A new set of APIs were developed to represent all of this information in a useful way to the developer - Detailed class nesting information available CDI needed a way to determine the enclosing class information for all types of inner classes. This is all calculated and presented via a few easy methods - Memory optimization work The overhead required to store all offline reflection info + generics is significant. Implemented a variety of graph reduction strategies. End results of a monster deployment containing 713MB of class data (> 100k classes > 1 million methods) = 120MB of memory usage. The JDK has 128MB of class data, which Jandex uses only 20MB of heap to store. -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat ----- End forwarded message ----- ----- End forwarded message ----- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 496 bytes Desc: not available Url : http://lists.jboss.org/pipermail/hibernate-dev/attachments/20141201/bab4d212/attachment.bin From golovnin at gmx.net Mon Dec 1 16:07:39 2014 From: golovnin at gmx.net (Andrej Golovnin) Date: Mon, 1 Dec 2014 22:07:39 +0100 Subject: [hibernate-dev] Closed pull requests In-Reply-To: References: <84D5AADC-23D4-4377-AED7-1EB88869FF30@gmx.net> <7B4B4720-5C93-43C7-BDD8-F515CAA1A4F6@gmx.net> Message-ID: <32A4A57E-E639-4DB9-9079-E88BB301F0DD@gmx.net> > They should get moved to the 4.3-based master. I think I found the relevant issues: > > * Oracle12cDialect - https://hibernate.atlassian.net/browse/HHH-9044 > * PostgreSQL92Dialect & PostgreSQL94Dialect - https://hibernate.atlassian.net/browse/HHH-9167 > > I have reopened them and targeted them for 5.0 Do you already know when they will get moved to the 4.3-based master? I think I should wait with my pull request until they get moved. From steve at hibernate.org Mon Dec 1 18:31:17 2014 From: steve at hibernate.org (Steve Ebersole) Date: Mon, 1 Dec 2014 17:31:17 -0600 Subject: [hibernate-dev] Closed pull requests In-Reply-To: <32A4A57E-E639-4DB9-9079-E88BB301F0DD@gmx.net> References: <84D5AADC-23D4-4377-AED7-1EB88869FF30@gmx.net> <7B4B4720-5C93-43C7-BDD8-F515CAA1A4F6@gmx.net> <32A4A57E-E639-4DB9-9079-E88BB301F0DD@gmx.net> Message-ID: I am finishing up the initial 5.0 work for master right now. I will work on these next. Ping me at the end of the week so I dont forget :) On Mon, Dec 1, 2014 at 3:07 PM, Andrej Golovnin wrote: > > > They should get moved to the 4.3-based master. I think I found the > relevant issues: > > > > * Oracle12cDialect - https://hibernate.atlassian.net/browse/HHH-9044 > > * PostgreSQL92Dialect & PostgreSQL94Dialect - > https://hibernate.atlassian.net/browse/HHH-9167 > > > > I have reopened them and targeted them for 5.0 > > Do you already know when they will get moved to the 4.3-based master? > I think I should wait with my pull request until they get moved. From steve at hibernate.org Mon Dec 1 18:33:39 2014 From: steve at hibernate.org (Steve Ebersole) Date: Mon, 1 Dec 2014 17:33:39 -0600 Subject: [hibernate-dev] Jandex 2.0 Beta - Java 8 Type Annotations, Generics, & Offline Reflection In-Reply-To: <20141201202423.GC20433@Sarmakand-4.lan> References: <20141201202423.GC20433@Sarmakand-4.lan> Message-ID: Yes, this is the new Jandex stuff I mentioned in Amsterdam. Moving to Jandex at all is one of the tasks we marked as optional for ORM 5.0. This would mean changing the legacy AnnotationBinder awesome-sauce to use Jandex, not the new metamodel code; so that would be a lot of work. Volunteers to help gets its done faster :) On Mon, Dec 1, 2014 at 2:24 PM, Hardy Ferentschik wrote: > Hi, > > I think this email of Jason is worth forwarding to hibernate-dev. > Jandex 2 sounds really interesting for all Hibernate projects. To a > certain degree Jandex offers now > a lot of the things Steve tried to do with the reflight stuff. I am not > sure whether Jandex can completely > replace it, but t can be for sure of help. Especially interesting to me is > the fully resolved type information. > > In Search we have been talking for a long time to get rid of Commons > Annotations. It is basically already possible > now (using Jandex 1), but it got pushed back so far. Now with Jandex 2 we > definitely should make the switch. Maybe Search 5.1? > > Last but not least Validator, there we have been talking about Jandex for > a while as well. The new version would not have > the benefit of being able to remove the dependency to classmate. > > I think we should have a look at this Beta and provide feedback to Jason > if we find any problems. I am for sure to have a look > at it in the context of Validator. > > --Hardy > > > ----- Forwarded message from Jason Greene ----- > > I normally don?t spam you guys with Beta announcements, but since many of > you are using Jandex, and this release has significant changes, in > particular additional APIs, I wanted to make sure there was an opportunity > for feedback before going final. > > For those unfamiliar with Jandex, it was originally created as an > efficient bytecode based annotation indexer for AS7, but over time has > evolved to also act as a reflection library that does not require > class-loading nor complete linkage (you can analyze partial class graphs). > > For those interested in playing with runtime Java 8 Type annotations, > which will likely end up in EE8 APIs, this release will likely be quite > useful to you, since standard Java reflection does not currently expose > this data. > > A brief guide for using Jandex is located here: > https://github.com/wildfly/jandex > > Full notes are below. > > Thanks! > > > > Jandex 2.0 > ????? > > - Binary and Source Compatibility > > All previous code *using* Jandex 1.1 should compile and run against 2.0. > However, any code that extended ?closed" contracts (e.g. > AnnotationTarget) > will require updating. > > - Offline reflective APIs and improvements > > All methods and fields, whether annotated or not are all accessible, and > supporting APIs were created to enable access to the information. > > Generics information is provided in a familiar pattern similar to Java > reflection but with usability improvements. Type information is fully > resolved. > > Method and field access now supports binary searchable. Annotations are > categorized and filtered at various levels. > > All need to cast has been eliminated from the framework. > > - Implemented offline index persistence > > The format is radically different to support the storage of > generics, type annotations, and the aggressive interning used to > reduce memory usage. Monster deployment (713MB of class data) > only requires 26MB of storage. JDK, which has 128MB of class data is > requires only 4.8 MB. Compressing the indexes by including them in a jar > reduces the capacity even further to about 14MB and 2.6 MB respectively. > > Loading time is extremely efficient, at 1 second to load the 26MB > index for the monster deployment. > > A portability layer is provided to convert the pervious > offline index formats into the new internal model. > > - Full Java 8 type annotation support > > Java 8 type annotations all you to use annotations almost anywhere. > For example, the following is now allowed: > > @A Map<@B Comparable<@F Object @C [] @D [] @E []>, @G List <@H D>> b; > @H O1. at E O2<@F S, @G T>. at D O3. at A Nested<@B U, @C V> bar6; > > A new set of APIs were developed to represent all of this information in > a useful way to the developer > > - Detailed class nesting information available > > CDI needed a way to determine the enclosing class information for > all types of inner classes. This is all calculated and presented via > a few easy methods > > - Memory optimization work > > The overhead required to store all offline reflection > info + generics is significant. Implemented a variety of graph > reduction strategies. > > End results of a monster deployment containing 713MB of class data > (> 100k classes > 1 million methods) = 120MB of memory usage. The > JDK has 128MB of class data, which Jandex uses > only 20MB of heap to store. > > -- > Jason T. Greene > WildFly Lead / JBoss EAP Platform Architect > JBoss, a division of Red Hat > > > > ----- End forwarded message ----- > > ----- End forwarded message ----- > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From gunnar at hibernate.org Tue Dec 2 03:00:15 2014 From: gunnar at hibernate.org (Gunnar Morling) Date: Tue, 2 Dec 2014 09:00:15 +0100 Subject: [hibernate-dev] org.hibernate.persister.spi.PersisterFactory and 5.0 In-Reply-To: References: Message-ID: 2014-12-01 18:28 GMT+01:00 Steve Ebersole : > As for the "parameter object", I came up with a decent (imo) solution. So > I only wrap the things that are "contextual". Here is the contract right > now: > > > public interface PersisterFactory extends Service { > /** > * "Parameter object" providing access to additional information that may > be needed > * in the creation of the persisters. > */ > public static interface PersisterCreationContext { > SessionFactoryImplementor getSessionFactory(); > Metadata getMetadata(); > } > > /** > * Create an entity persister instance. > * > * @param entityBinding The mapping information describing the entity > * @param entityCacheAccessStrategy The cache access strategy for the > entity region > * @param naturalIdCacheAccessStrategy The cache access strategy for the > entity's natural-id cross-ref region > * @param creationContext Access to additional information needed to > create an EntityPersister > * > * @return An appropriate entity persister instance. > * > * @throws HibernateException Indicates a problem building the persister. > */ > public EntityPersister createEntityPersister( > PersistentClass entityBinding, > EntityRegionAccessStrategy entityCacheAccessStrategy, > NaturalIdRegionAccessStrategy naturalIdCacheAccessStrategy, > PersisterCreationContext creationContext) throws HibernateException; > > /** > * Create a collection persister instance. > * > * @param collectionBinding The mapping information describing the > collection > * @param cacheAccessStrategy The cache access strategy for the collection > region > * @param creationContext Access to additional information needed to > create an EntityPersister > * > * @return An appropriate collection persister instance. > * > * @throws HibernateException Indicates a problem building the persister. > */ > public CollectionPersister createCollectionPersister( > Collection collectionBinding, > CollectionRegionAccessStrategy cacheAccessStrategy, > PersisterCreationContext creationContext) throws HibernateException; > > } > > PersisterCreationContext is the contextual info. And it can be > "statically" defined for each and every call into PersisterFactory. The > other params to #createEntityPersister and #createCollectionPersister are > specific to that call. > Why did you decide against putting all the parameters into the context object? Do you think the allocations of the context object are a problem? Persisters are cached, so I wouldn't expect this to be an issue really? With the suggested approach one would still have incompatible changes when adding "non static" data to the argument list in the future. Not sure though how likely that is. On Thu, Nov 27, 2014 at 10:35 AM, Steve Ebersole > wrote: > >> Actually, I take that back about Metadata extending org.hibernate.cfg.Mappings. >> I had contemplated doing that, but decided against it since Mappings >> exposes all kinds of "extra" stuff that isn't actually mappings/metadata >> (config info, contextual info, etc) and I did not want to fuglify these new >> contracts that way. >> >> On Thu, Nov 27, 2014 at 10:25 AM, Steve Ebersole >> wrote: >> >>> Well naturally there is still access to all this information :) >>> >>> IMO SessionFactoryObserver is a hack way of doing this. With 5.0, the >>> way to do this would be one of the various bootstrap hooks I mentioned >>> earlier. Specifically you want a hook that is called just after all >>> metadata is fully known. >>> >>> BTW, for 5.0 the "metadata" is still using the mappings as defined in >>> the org.hibernate.mapping package. So all that code fragment will continue >>> to work aside from actually using the Configuration. Interestingly, >>> had you used org.hibernate.cfg.Mappings#iterateTables rather than >>> Configuration#getTableMappings(), this code would have continued to >>> work with no changes at all. This is the point I made in the initial email >>> about Metadata also being a org.hibernate.cfg.Mappings. >>> >>> >>> On Thu, Nov 27, 2014 at 4:36 AM, Emmanuel Bernard < >>> emmanuel at hibernate.org> wrote: >>> >>>> To add on Gunnar?s needs >>>> >>>> 3. Use Configuration to extract physical Table structure >>>> >>>> We also use configuration in the SchemaDefiner >>>> The SchemaDefiner received the Configuration from a custom >>>> implementation of SessionFactoryObserver and use it during >>>> sessionFactoryCreated. >>>> >>>> The reason we use Configuration is so that this SchemaDefiner contract >>>> can: >>>> >>>> - access to specific properties (say hibernate.0gm.neo4j.index >>>> create-drop ) >>>> - get information about the table, it?s unique constraints as shown in >>>> this pseudo example >>>> >>>> Iterator
tableMappings = configuration.getTableMappings(); >>>> while ( tableMappings.hasNext() ) { >>>> Table table = tableMappings.next(); >>>> if ( table.isPhysicalTable() ) { >>>> Label label = label( table.getName() ); >>>> PrimaryKey primaryKey = table.getPrimaryKey(); >>>> createConstraint( neo4jDb, table, label, primaryKey ); >>>> @SuppressWarnings("unchecked") >>>> Iterator columnIterator = table.getColumnIterator(); >>>> while ( columnIterator.hasNext() ) { >>>> Column column = columnIterator.next(); >>>> if ( column.isUnique() ) { >>>> createUniqueConstraintIfMissing( neo4jDb, label, >>>> column.getName() ); >>>> } >>>> } >>>> Iterator uniqueKeyIterator = >>>> table.getUniqueKeyIterator(); >>>> while ( uniqueKeyIterator.hasNext() ) { >>>> createConstraint( neo4jDb, table, label, >>>> uniqueKeyIterator.next() ); >>>> } >>>> } >>>> } >>>> >>>> >>>> >>>> >>>> On 27 Nov 2014, at 10:13, Gunnar Morling wrote: >>>> >>>> Hi, >>>> >>>> 2014-11-27 1:23 GMT+01:00 Steve Ebersole : >>>> >>>> Part of the goals for ORM 5.0 is moving from Configuration to the >>>> ServiceRegistry+Metadata for building a SessionFactory. >>>> >>>> One of the points I ran into that will have to change >>>> is org.hibernate.persister.spi.PersisterFactory. The problems is that >>>> PersisterFactory accepts a Configuration as part of building >>>> CollectionPersisters. The need for Configuration in the standard >>>> CollectionPersister impls is amazingly trivial; we literally use it to >>>> locate the associated entity's PersistentClass to grab the classes dom4j >>>> node name, and this is right after we have just resolved the >>>> corresponding >>>> EntityPersister. The point being that the standard CollectionPersisters >>>> really don't need access to the Configuration. >>>> >>>> I am pretty sure OGM provides a custom PersisterFactory, or is it just >>>> the PersisterClassResolver that OGM provides? Also, I would assume OGM >>>> is >>>> providing custom CollectionPersister impls. This change would affect >>>> both >>>> usages. >>>> >>>> >>>> We don't have a custom PersisterFactory, but there are >>>> OgmPersisterClassResolver [1] and OgmCollectionPersister [2]. In the >>>> latter >>>> we accept a Configuration in the constructor but just pass it to the >>>> super >>>> 'ctor (AbstractCollectionPersister). We don't do anything ourselves >>>> with it. >>>> >>>> >>>> I wanted y'all to be aware of this upcoming change. But I also wanted >>>> to >>>> start a discussion about what the signature(s) should become. >>>> Currently we >>>> pass: >>>> >>>> * Configuration >>>> * Collection (the parsed mapping info) >>>> * CollectionRegionAccessStrategy >>>> * SessionFactoryImplementor >>>> >>>> >>>> I suggest we pass: >>>> >>>> * Collection >>>> * CollectionRegionAccessStrategy >>>> * SessionFactoryImplementor >>>> * Mapping >>>> >>>> >>>> Should be fine for OGM. I suggest to wrap it into a parameter object >>>> ("PersisterInitializationContext" or so). That way stuff can be added >>>> down >>>> the road without the need to instantly adapt existing persisters. >>>> >>>> (I changed order to align with the order for building EntityPersisters) >>>> >>>> >>>> Mapping is org.hibernate.engine.spi.Mapping which is part of >>>> Configuration. I decided to (at least temporarily) port this contract >>>> forward to ease migration. Metadata implements it. >>>> >>>> There is a similar discussion to be had wrt Integrators. I will follow >>>> up >>>> with an email specific to them later. >>>> >>>> >>>> Regarding the removal of Configuration in general, there will be some >>>> more >>>> work to be done in OGM. We have a custom sub-class, OgmConfiguration >>>> [3], >>>> which is used for two purposes: >>>> >>>> 1) Set some properties automatically (to enable OGM's naming strategy >>>> and >>>> query translator etc., use a specific mass indexer for Hibernate Search) >>>> 2) Provide an entry point into the API for setting store specific >>>> options, >>>> e.g. like so: >>>> >>>> OgmConfiguration ogmCfg = ...; >>>> ogmCfg.configureOptionsFor( MongoDB.class ) >>>> .entity( GolfPlayer.class ) >>>> .writeConcern( WriteConcernType.REPLICA_ACKNOWLEDGED ); >>>> >>>> We'll need a way to still do 1). >>>> >>>> 2) is not really required. We provide an alternative anyways, for cases >>>> where you don't bootstrap OGM yourself. You can specify a callback class >>>> via configuration properties, which then will be invoked and provides >>>> the >>>> entry point to the fluent API. >>>> >>>> --Gunnar >>>> >>>> [1] >>>> >>>> https://github.com/hibernate/hibernate-ogm/blob/master/core/src/main/java/org/hibernate/ogm/jpa/impl/OgmPersisterClassResolver.java >>>> [2] >>>> >>>> https://github.com/hibernate/hibernate-ogm/blob/master/core/src/main/java/org/hibernate/ogm/persister/impl/OgmCollectionPersister.java >>>> [3] >>>> >>>> https://github.com/hibernate/hibernate-ogm/blob/master/core/src/main/java/org/hibernate/ogm/cfg/OgmConfiguration.java >>>> >>>> >>>> >>>> _______________________________________________ >>>> hibernate-dev mailing list >>>> hibernate-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>> >>>> _______________________________________________ >>>> hibernate-dev mailing list >>>> hibernate-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>> >>>> >>>> >>> >> > From gunnar at hibernate.org Tue Dec 2 03:15:38 2014 From: gunnar at hibernate.org (Gunnar Morling) Date: Tue, 2 Dec 2014 09:15:38 +0100 Subject: [hibernate-dev] org.hibernate.persister.spi.PersisterFactory and 5.0 In-Reply-To: References: Message-ID: 2014-12-01 21:22 GMT+01:00 Steve Ebersole : > Wanted to point out that I carried those signatures on to the persister > ctors as well. > Thx. In Amsterdam we had talked about OGM needing a bootstrap hook for the point > just after all persisters have been built. Exactly what information did > that hook need access to? > We'd need access to all the entity and collection persisters. For each property which represents the main side of a bi-directional association, we want to determine the persister on the other side, so we can fetch some OGM-specific metadata from it. In a local prototype, I added a parameterless method doDeferredPostInstantiate() to OgmEntityPersister which I invoke by means of an observer. From there I obtain the other persisters through the SF. On Mon, Dec 1, 2014 at 11:28 AM, Steve Ebersole wrote: > >> As for the "parameter object", I came up with a decent (imo) solution. >> So I only wrap the things that are "contextual". Here is the contract >> right now: >> >> >> public interface PersisterFactory extends Service { >> /** >> * "Parameter object" providing access to additional information that may >> be needed >> * in the creation of the persisters. >> */ >> public static interface PersisterCreationContext { >> SessionFactoryImplementor getSessionFactory(); >> Metadata getMetadata(); >> } >> >> /** >> * Create an entity persister instance. >> * >> * @param entityBinding The mapping information describing the entity >> * @param entityCacheAccessStrategy The cache access strategy for the >> entity region >> * @param naturalIdCacheAccessStrategy The cache access strategy for the >> entity's natural-id cross-ref region >> * @param creationContext Access to additional information needed to >> create an EntityPersister >> * >> * @return An appropriate entity persister instance. >> * >> * @throws HibernateException Indicates a problem building the persister. >> */ >> public EntityPersister createEntityPersister( >> PersistentClass entityBinding, >> EntityRegionAccessStrategy entityCacheAccessStrategy, >> NaturalIdRegionAccessStrategy naturalIdCacheAccessStrategy, >> PersisterCreationContext creationContext) throws HibernateException; >> >> /** >> * Create a collection persister instance. >> * >> * @param collectionBinding The mapping information describing the >> collection >> * @param cacheAccessStrategy The cache access strategy for the >> collection region >> * @param creationContext Access to additional information needed to >> create an EntityPersister >> * >> * @return An appropriate collection persister instance. >> * >> * @throws HibernateException Indicates a problem building the persister. >> */ >> public CollectionPersister createCollectionPersister( >> Collection collectionBinding, >> CollectionRegionAccessStrategy cacheAccessStrategy, >> PersisterCreationContext creationContext) throws HibernateException; >> >> } >> >> PersisterCreationContext is the contextual info. And it can be >> "statically" defined for each and every call into PersisterFactory. The >> other params to #createEntityPersister and #createCollectionPersister are >> specific to that call. >> >> >> On Thu, Nov 27, 2014 at 10:35 AM, Steve Ebersole >> wrote: >> >>> Actually, I take that back about Metadata extending org.hibernate.cfg.Mappings. >>> I had contemplated doing that, but decided against it since Mappings >>> exposes all kinds of "extra" stuff that isn't actually mappings/metadata >>> (config info, contextual info, etc) and I did not want to fuglify these new >>> contracts that way. >>> >>> On Thu, Nov 27, 2014 at 10:25 AM, Steve Ebersole >>> wrote: >>> >>>> Well naturally there is still access to all this information :) >>>> >>>> IMO SessionFactoryObserver is a hack way of doing this. With 5.0, the >>>> way to do this would be one of the various bootstrap hooks I mentioned >>>> earlier. Specifically you want a hook that is called just after all >>>> metadata is fully known. >>>> >>>> BTW, for 5.0 the "metadata" is still using the mappings as defined in >>>> the org.hibernate.mapping package. So all that code fragment will continue >>>> to work aside from actually using the Configuration. Interestingly, >>>> had you used org.hibernate.cfg.Mappings#iterateTables rather than >>>> Configuration#getTableMappings(), this code would have continued to >>>> work with no changes at all. This is the point I made in the initial email >>>> about Metadata also being a org.hibernate.cfg.Mappings. >>>> >>>> >>>> On Thu, Nov 27, 2014 at 4:36 AM, Emmanuel Bernard < >>>> emmanuel at hibernate.org> wrote: >>>> >>>>> To add on Gunnar?s needs >>>>> >>>>> 3. Use Configuration to extract physical Table structure >>>>> >>>>> We also use configuration in the SchemaDefiner >>>>> The SchemaDefiner received the Configuration from a custom >>>>> implementation of SessionFactoryObserver and use it during >>>>> sessionFactoryCreated. >>>>> >>>>> The reason we use Configuration is so that this SchemaDefiner contract >>>>> can: >>>>> >>>>> - access to specific properties (say hibernate.0gm.neo4j.index >>>>> create-drop ) >>>>> - get information about the table, it?s unique constraints as shown in >>>>> this pseudo example >>>>> >>>>> Iterator
tableMappings = configuration.getTableMappings(); >>>>> while ( tableMappings.hasNext() ) { >>>>> Table table = tableMappings.next(); >>>>> if ( table.isPhysicalTable() ) { >>>>> Label label = label( table.getName() ); >>>>> PrimaryKey primaryKey = table.getPrimaryKey(); >>>>> createConstraint( neo4jDb, table, label, primaryKey ); >>>>> @SuppressWarnings("unchecked") >>>>> Iterator columnIterator = table.getColumnIterator(); >>>>> while ( columnIterator.hasNext() ) { >>>>> Column column = columnIterator.next(); >>>>> if ( column.isUnique() ) { >>>>> createUniqueConstraintIfMissing( neo4jDb, label, >>>>> column.getName() ); >>>>> } >>>>> } >>>>> Iterator uniqueKeyIterator = >>>>> table.getUniqueKeyIterator(); >>>>> while ( uniqueKeyIterator.hasNext() ) { >>>>> createConstraint( neo4jDb, table, label, >>>>> uniqueKeyIterator.next() ); >>>>> } >>>>> } >>>>> } >>>>> >>>>> >>>>> >>>>> >>>>> On 27 Nov 2014, at 10:13, Gunnar Morling wrote: >>>>> >>>>> Hi, >>>>> >>>>> 2014-11-27 1:23 GMT+01:00 Steve Ebersole : >>>>> >>>>> Part of the goals for ORM 5.0 is moving from Configuration to the >>>>> ServiceRegistry+Metadata for building a SessionFactory. >>>>> >>>>> One of the points I ran into that will have to change >>>>> is org.hibernate.persister.spi.PersisterFactory. The problems is that >>>>> PersisterFactory accepts a Configuration as part of building >>>>> CollectionPersisters. The need for Configuration in the standard >>>>> CollectionPersister impls is amazingly trivial; we literally use it to >>>>> locate the associated entity's PersistentClass to grab the classes >>>>> dom4j >>>>> node name, and this is right after we have just resolved the >>>>> corresponding >>>>> EntityPersister. The point being that the standard >>>>> CollectionPersisters >>>>> really don't need access to the Configuration. >>>>> >>>>> I am pretty sure OGM provides a custom PersisterFactory, or is it just >>>>> the PersisterClassResolver that OGM provides? Also, I would assume >>>>> OGM is >>>>> providing custom CollectionPersister impls. This change would affect >>>>> both >>>>> usages. >>>>> >>>>> >>>>> We don't have a custom PersisterFactory, but there are >>>>> OgmPersisterClassResolver [1] and OgmCollectionPersister [2]. In the >>>>> latter >>>>> we accept a Configuration in the constructor but just pass it to the >>>>> super >>>>> 'ctor (AbstractCollectionPersister). We don't do anything ourselves >>>>> with it. >>>>> >>>>> >>>>> I wanted y'all to be aware of this upcoming change. But I also wanted >>>>> to >>>>> start a discussion about what the signature(s) should become. >>>>> Currently we >>>>> pass: >>>>> >>>>> * Configuration >>>>> * Collection (the parsed mapping info) >>>>> * CollectionRegionAccessStrategy >>>>> * SessionFactoryImplementor >>>>> >>>>> >>>>> I suggest we pass: >>>>> >>>>> * Collection >>>>> * CollectionRegionAccessStrategy >>>>> * SessionFactoryImplementor >>>>> * Mapping >>>>> >>>>> >>>>> Should be fine for OGM. I suggest to wrap it into a parameter object >>>>> ("PersisterInitializationContext" or so). That way stuff can be added >>>>> down >>>>> the road without the need to instantly adapt existing persisters. >>>>> >>>>> (I changed order to align with the order for building EntityPersisters) >>>>> >>>>> >>>>> Mapping is org.hibernate.engine.spi.Mapping which is part of >>>>> Configuration. I decided to (at least temporarily) port this contract >>>>> forward to ease migration. Metadata implements it. >>>>> >>>>> There is a similar discussion to be had wrt Integrators. I will >>>>> follow up >>>>> with an email specific to them later. >>>>> >>>>> >>>>> Regarding the removal of Configuration in general, there will be some >>>>> more >>>>> work to be done in OGM. We have a custom sub-class, OgmConfiguration >>>>> [3], >>>>> which is used for two purposes: >>>>> >>>>> 1) Set some properties automatically (to enable OGM's naming strategy >>>>> and >>>>> query translator etc., use a specific mass indexer for Hibernate >>>>> Search) >>>>> 2) Provide an entry point into the API for setting store specific >>>>> options, >>>>> e.g. like so: >>>>> >>>>> OgmConfiguration ogmCfg = ...; >>>>> ogmCfg.configureOptionsFor( MongoDB.class ) >>>>> .entity( GolfPlayer.class ) >>>>> .writeConcern( WriteConcernType.REPLICA_ACKNOWLEDGED ); >>>>> >>>>> We'll need a way to still do 1). >>>>> >>>>> 2) is not really required. We provide an alternative anyways, for cases >>>>> where you don't bootstrap OGM yourself. You can specify a callback >>>>> class >>>>> via configuration properties, which then will be invoked and provides >>>>> the >>>>> entry point to the fluent API. >>>>> >>>>> --Gunnar >>>>> >>>>> [1] >>>>> >>>>> https://github.com/hibernate/hibernate-ogm/blob/master/core/src/main/java/org/hibernate/ogm/jpa/impl/OgmPersisterClassResolver.java >>>>> [2] >>>>> >>>>> https://github.com/hibernate/hibernate-ogm/blob/master/core/src/main/java/org/hibernate/ogm/persister/impl/OgmCollectionPersister.java >>>>> [3] >>>>> >>>>> https://github.com/hibernate/hibernate-ogm/blob/master/core/src/main/java/org/hibernate/ogm/cfg/OgmConfiguration.java >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> hibernate-dev mailing list >>>>> hibernate-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>> >>>>> _______________________________________________ >>>>> hibernate-dev mailing list >>>>> hibernate-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>> >>>>> >>>>> >>>> >>> >> > From emmanuel at hibernate.org Tue Dec 2 03:23:23 2014 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Tue, 2 Dec 2014 09:23:23 +0100 Subject: [hibernate-dev] Maintenance on ci.hibernate.org In-Reply-To: References: Message-ID: <4B456883-34C3-4EE1-961E-D136645A9D21@hibernate.org> The website returns "Service Unavailable?. What is the expected downtime window? > On 01 Dec 2014, at 13:34, Davide D'Alto wrote: > > On a related note, > I've also reinstalled couchdb since it stopped working for some reason. > > I've also changed the maven version used for hibernate-ogm-master-jdk9 to > maven 3.2.3. > Maven 3.2.3 fixes some some bugs related to the profiles activation. > > Davide > > > On Sun, Nov 30, 2014 at 10:22 PM, Sanne Grinovero > wrote: > >> All, >> we needed to do some unplanned maintenance on ci.hibernate.org. >> >> At some point it was clear that we needed do deploy some significant >> upgrades so while Davide fixed Apache HTTPD, I went ahead and updated >> all of Jenkins plugins as well.. which I usually avoid to not need >> checking all builds and integrations with external services, but this >> time all validations would be needed anyway. >> >> So: >> - I'm sorry if you received some false notifications from it. >> - If some builds are now broken, it might need some reconfiguration. >> - same for plugins configurations: I'm unable to double-check all >> things you've all setup. >> >> Please let me know what isn't working anymore, or if you have a moment >> to volunteer looking yourself that would be great. >> >> # Reminder >> Anyone in the Hibernate organization on GitHub has configuration and >> write permissions on this server; if you know what you're doing feel >> free to take advantage of that but please always share a summary of >> what you did / plan to do. >> >> Sanne >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From gunnar at hibernate.org Tue Dec 2 03:37:26 2014 From: gunnar at hibernate.org (Gunnar Morling) Date: Tue, 2 Dec 2014 09:37:26 +0100 Subject: [hibernate-dev] Making it pluggable how GenerationType.AUTO is mapped In-Reply-To: References: Message-ID: Yes, it would be great to have this in ORM 5.0. Currently, AUTO is a bit AWKWARD to use with MongoDB; if USE_NEW_ID_GENERATOR_MAPPINGS is set to false, we map AUTO to IDENTITY (via Dialect#getNativeIdentifierGeneratorClass()) which only works if the id type is MongoDB's ObjectId type or a String marked with @Type("objectid"). And if USE_NEW_ID_GENERATOR_MAPPINGS is set to true, it will be mapped to the sequence strategy (as per the logic in ORM). This in turn only works if the id is of a numeric type. So it's quite easy for the user to run into misconfigurations here. I've filed https://hibernate.atlassian.net/browse/HHH-9524 to track this requirement and catch the discussion. Thanks, --Gunnar > 2014-12-01 18:25 GMT+01:00 Steve Ebersole : > >> Maybe. I'll have to look a little closer. Is this something you are >> looking at for use with ORM 5.0? >> >> On Fri, Nov 28, 2014 at 5:08 AM, Gunnar Morling >> wrote: >> >>> Hi Steve, all, >>> >>> For OGM it would be beneficial if there was an extension point in ORM >>> which >>> allows us to customize how GenerationType.AUTO is mapped. AFAICS, that's >>> currently semi-hard coded in ORM. Depending on whether >>> "new_generator_mappings" is set, either SEQUENCE (true) or "native" >>> (false) >>> will be used. >>> >>> Now for the MongoDB grid dialect we'd ideally do the following: If the id >>> of an entity is declared as >>> >>> org.bson.typesObjectId >>> >>> or >>> >>> @Type(type = "objectid") String >>> >>> then map AUTO to IDENTITY (ObjectId is a MongoDB-specific type which >>> resembles an identity column). Otherwise map it to TABLE (or SEQUENCE, >>> which transparently falls back to TABLE). >>> >>> I.e. this decision would not be a global one, but depend on the specific >>> id >>> type. >>> >>> Would this be feasible to do? or is it mandated by JPA somehow that AUTO >>> is >>> always mapped in the same way? I cannot judge on the amount of changes >>> required in ORM as atm. AUTO always is mapped in the same way, it doesn't >>> depend on the specific entity and its id type. >>> >>> Any thoughts? >>> >>> Thanks, >>> >>> --Gunnar >>> _______________________________________________ >>> hibernate-dev mailing list >>> hibernate-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> >> >> > From emmanuel at hibernate.org Tue Dec 2 03:39:56 2014 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Tue, 2 Dec 2014 09:39:56 +0100 Subject: [hibernate-dev] Maintenance on ci.hibernate.org In-Reply-To: <4B456883-34C3-4EE1-961E-D136645A9D21@hibernate.org> References: <4B456883-34C3-4EE1-961E-D136645A9D21@hibernate.org> Message-ID: Seems to be back up but the staging website is not available and redirects to the ci website. https://hibernate.atlassian.net/browse/WEBSITE-235 Keep me posted when it?s fixed. I have pending tests I need to do on the staging website. Emmanuel > On 02 Dec 2014, at 09:23, Emmanuel Bernard wrote: > > The website returns "Service Unavailable?. > What is the expected downtime window? > >> On 01 Dec 2014, at 13:34, Davide D'Alto wrote: >> >> On a related note, >> I've also reinstalled couchdb since it stopped working for some reason. >> >> I've also changed the maven version used for hibernate-ogm-master-jdk9 to >> maven 3.2.3. >> Maven 3.2.3 fixes some some bugs related to the profiles activation. >> >> Davide >> >> >> On Sun, Nov 30, 2014 at 10:22 PM, Sanne Grinovero >> wrote: >> >>> All, >>> we needed to do some unplanned maintenance on ci.hibernate.org. >>> >>> At some point it was clear that we needed do deploy some significant >>> upgrades so while Davide fixed Apache HTTPD, I went ahead and updated >>> all of Jenkins plugins as well.. which I usually avoid to not need >>> checking all builds and integrations with external services, but this >>> time all validations would be needed anyway. >>> >>> So: >>> - I'm sorry if you received some false notifications from it. >>> - If some builds are now broken, it might need some reconfiguration. >>> - same for plugins configurations: I'm unable to double-check all >>> things you've all setup. >>> >>> Please let me know what isn't working anymore, or if you have a moment >>> to volunteer looking yourself that would be great. >>> >>> # Reminder >>> Anyone in the Hibernate organization on GitHub has configuration and >>> write permissions on this server; if you know what you're doing feel >>> free to take advantage of that but please always share a summary of >>> what you did / plan to do. >>> >>> Sanne >>> _______________________________________________ >>> hibernate-dev mailing list >>> hibernate-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From emmanuel at hibernate.org Tue Dec 2 04:03:00 2014 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Tue, 2 Dec 2014 10:03:00 +0100 Subject: [hibernate-dev] Maintenance on ci.hibernate.org In-Reply-To: References: <4B456883-34C3-4EE1-961E-D136645A9D21@hibernate.org> Message-ID: Another problem on the permission side https://hibernate.atlassian.net/browse/WEBSITE-236 > On 02 Dec 2014, at 09:39, Emmanuel Bernard wrote: > > Seems to be back up but the staging website is not available and redirects to the ci website. > https://hibernate.atlassian.net/browse/WEBSITE-235 > > Keep me posted when it?s fixed. I have pending tests I need to do on the staging website. > > Emmanuel > >> On 02 Dec 2014, at 09:23, Emmanuel Bernard wrote: >> >> The website returns "Service Unavailable?. >> What is the expected downtime window? >> >>> On 01 Dec 2014, at 13:34, Davide D'Alto wrote: >>> >>> On a related note, >>> I've also reinstalled couchdb since it stopped working for some reason. >>> >>> I've also changed the maven version used for hibernate-ogm-master-jdk9 to >>> maven 3.2.3. >>> Maven 3.2.3 fixes some some bugs related to the profiles activation. >>> >>> Davide >>> >>> >>> On Sun, Nov 30, 2014 at 10:22 PM, Sanne Grinovero >>> wrote: >>> >>>> All, >>>> we needed to do some unplanned maintenance on ci.hibernate.org. >>>> >>>> At some point it was clear that we needed do deploy some significant >>>> upgrades so while Davide fixed Apache HTTPD, I went ahead and updated >>>> all of Jenkins plugins as well.. which I usually avoid to not need >>>> checking all builds and integrations with external services, but this >>>> time all validations would be needed anyway. >>>> >>>> So: >>>> - I'm sorry if you received some false notifications from it. >>>> - If some builds are now broken, it might need some reconfiguration. >>>> - same for plugins configurations: I'm unable to double-check all >>>> things you've all setup. >>>> >>>> Please let me know what isn't working anymore, or if you have a moment >>>> to volunteer looking yourself that would be great. >>>> >>>> # Reminder >>>> Anyone in the Hibernate organization on GitHub has configuration and >>>> write permissions on this server; if you know what you're doing feel >>>> free to take advantage of that but please always share a summary of >>>> what you did / plan to do. >>>> >>>> Sanne >>>> _______________________________________________ >>>> hibernate-dev mailing list >>>> hibernate-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>> >>> _______________________________________________ >>> hibernate-dev mailing list >>> hibernate-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >> >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From hardy at hibernate.org Tue Dec 2 04:45:28 2014 From: hardy at hibernate.org (Hardy Ferentschik) Date: Tue, 2 Dec 2014 10:45:28 +0100 Subject: [hibernate-dev] Jandex 2.0 Beta - Java 8 Type Annotations, Generics, & Offline Reflection In-Reply-To: References: <20141201202423.GC20433@Sarmakand-4.lan> Message-ID: <20141202094528.GD20433@Sarmakand-4.lan> Hi, On Mon, Dec 01, 2014 at 05:33:39PM -0600, Steve Ebersole wrote: > Yes, this is the new Jandex stuff I mentioned in Amsterdam Right. > Moving to Jandex at all is one of the tasks we marked as optional for ORM 5.0. Ahh, I was hoping it would be part of ORM 5.0, but given the new scope it makes sense that it is only optional now. > This would mean changing the legacy AnnotationBinder awesome-sauce to use > Jandex, not the new metamodel code; so that would be a lot of work. Right :-( That's for sure not a trivial task. > Volunteers to help gets its done faster :) :-) --Hardy -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 496 bytes Desc: not available Url : http://lists.jboss.org/pipermail/hibernate-dev/attachments/20141202/d18e0d76/attachment.bin From gunnar at hibernate.org Tue Dec 2 05:09:03 2014 From: gunnar at hibernate.org (Gunnar Morling) Date: Tue, 2 Dec 2014 11:09:03 +0100 Subject: [hibernate-dev] Jandex 2.0 Beta - Java 8 Type Annotations, Generics, & Offline Reflection In-Reply-To: <20141201202423.GC20433@Sarmakand-4.lan> References: <20141201202423.GC20433@Sarmakand-4.lan> Message-ID: 2014-12-01 21:24 GMT+01:00 Hardy Ferentschik : > Hi, > > I think this email of Jason is worth forwarding to hibernate-dev. > Jandex 2 sounds really interesting for all Hibernate projects. To a > certain degree Jandex offers now > a lot of the things Steve tried to do with the reflight stuff. I am not > sure whether Jandex can completely > replace it, but t can be for sure of help. Especially interesting to me is > the fully resolved type information. > > In Search we have been talking for a long time to get rid of Commons > Annotations. It is basically already possible > now (using Jandex 1), but it got pushed back so far. Now with Jandex 2 we > definitely should make the switch. Maybe Search 5.1? > Out of interest, what would be the benefit for Search? > > Last but not least Validator, there we have been talking about Jandex for > a while as well. The new version would not have > the benefit of being able to remove the dependency to classmate. > I guess you mean it *would have* the benefit, right? Of course that comes at the price of adding another dependency, so that's not really an advantage per se for me :) I think we should have a look at this Beta and provide feedback to Jason if > we find any problems. I am for sure to have a look > at it in the context of Validator. > I find being able to re-use the index generated by the application container very useful. It would give a nice performance boost out of the box when using HV on WildFly/EAP. The type annotation stuff may be useful, but it's not that this information cannot be accessed via reflection at all. There are known issues with corner cases, though. So Jandex may improve the situation for us. Are there other advantages you expect from a HV perspective? I'm asking to make sure we're on the same page regarding what we expect from using Jandex in terms of user-visible features/improvements. > > --Hardy > > > ----- Forwarded message from Jason Greene ----- > > I normally don?t spam you guys with Beta announcements, but since many of > you are using Jandex, and this release has significant changes, in > particular additional APIs, I wanted to make sure there was an opportunity > for feedback before going final. > > For those unfamiliar with Jandex, it was originally created as an > efficient bytecode based annotation indexer for AS7, but over time has > evolved to also act as a reflection library that does not require > class-loading nor complete linkage (you can analyze partial class graphs). > > For those interested in playing with runtime Java 8 Type annotations, > which will likely end up in EE8 APIs, this release will likely be quite > useful to you, since standard Java reflection does not currently expose > this data. > > A brief guide for using Jandex is located here: > https://github.com/wildfly/jandex > > Full notes are below. > > Thanks! > > > > Jandex 2.0 > ????? > > - Binary and Source Compatibility > > All previous code *using* Jandex 1.1 should compile and run against 2.0. > However, any code that extended ?closed" contracts (e.g. > AnnotationTarget) > will require updating. > > - Offline reflective APIs and improvements > > All methods and fields, whether annotated or not are all accessible, and > supporting APIs were created to enable access to the information. > > Generics information is provided in a familiar pattern similar to Java > reflection but with usability improvements. Type information is fully > resolved. > > Method and field access now supports binary searchable. Annotations are > categorized and filtered at various levels. > > All need to cast has been eliminated from the framework. > > - Implemented offline index persistence > > The format is radically different to support the storage of > generics, type annotations, and the aggressive interning used to > reduce memory usage. Monster deployment (713MB of class data) > only requires 26MB of storage. JDK, which has 128MB of class data is > requires only 4.8 MB. Compressing the indexes by including them in a jar > reduces the capacity even further to about 14MB and 2.6 MB respectively. > > Loading time is extremely efficient, at 1 second to load the 26MB > index for the monster deployment. > > A portability layer is provided to convert the pervious > offline index formats into the new internal model. > > - Full Java 8 type annotation support > > Java 8 type annotations all you to use annotations almost anywhere. > For example, the following is now allowed: > > @A Map<@B Comparable<@F Object @C [] @D [] @E []>, @G List <@H D>> b; > @H O1. at E O2<@F S, @G T>. at D O3. at A Nested<@B U, @C V> bar6; > > A new set of APIs were developed to represent all of this information in > a useful way to the developer > > - Detailed class nesting information available > > CDI needed a way to determine the enclosing class information for > all types of inner classes. This is all calculated and presented via > a few easy methods > > - Memory optimization work > > The overhead required to store all offline reflection > info + generics is significant. Implemented a variety of graph > reduction strategies. > > End results of a monster deployment containing 713MB of class data > (> 100k classes > 1 million methods) = 120MB of memory usage. The > JDK has 128MB of class data, which Jandex uses > only 20MB of heap to store. > > -- > Jason T. Greene > WildFly Lead / JBoss EAP Platform Architect > JBoss, a division of Red Hat > > > > ----- End forwarded message ----- > > ----- End forwarded message ----- > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From hardy at hibernate.org Tue Dec 2 05:29:50 2014 From: hardy at hibernate.org (Hardy Ferentschik) Date: Tue, 2 Dec 2014 11:29:50 +0100 Subject: [hibernate-dev] Jandex 2.0 Beta - Java 8 Type Annotations, Generics, & Offline Reflection In-Reply-To: References: <20141201202423.GC20433@Sarmakand-4.lan> Message-ID: <20141202102950.GF20433@Sarmakand-4.lan> Hi, > > In Search we have been talking for a long time to get rid of Commons > > Annotations. It is basically already possible > > now (using Jandex 1), but it got pushed back so far. Now with Jandex 2 we > > definitely should make the switch. Maybe Search 5.1? > > > > Out of interest, what would be the benefit for Search? Getting rid of Commons Annotations. That is a long standing task. The annotation processing code could be simplified a fair bit in this case. The other advantage would be that in the case where Search is running in the container, we could just take an existing Jandex index at bootstrap (instead of building one ourselves). This would give a bit of boot speed-up. > > Last but not least Validator, there we have been talking about Jandex for > > a while as well. The new version would not have > > the benefit of being able to remove the dependency to classmate. > > I guess you mean it *would have* the benefit, right? sure :-) > Of course that comes at the price of adding another dependency, so that's > not really an advantage per se for me :) Not per se, but we already talked about consuming a Jandex index as part of the Bean Validation integration into Wildfly using CDI. In fact you seemed to be quite keen back then to give it a go. Now we could do it without increasing the amount of dependencies. > I think we should have a look at this Beta and provide feedback to Jason if > > we find any problems. I am for sure to have a look > > at it in the context of Validator. > > > > I find being able to re-use the index generated by the application > container very useful. It would give a nice performance boost out of the > box when using HV on WildFly/EAP. Exactly. > The type annotation stuff may be useful, but it's not that this information > cannot be accessed via reflection at all. There are known issues with > corner cases, though. So Jandex may improve the situation for us. My hope is that code would be simpler by using a single library for doing all reflection stuff including Java 8 type annotations, generic type resolution, etc > I'm asking to make sure we're on the same page regarding what we expect > from using Jandex in terms of user-visible features/improvements. Right, this is not about adding new features for the user. The user might get some speed-up and maybe less memory consumption, but otherwise we are talking about internal changes. --Hardy -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 496 bytes Desc: not available Url : http://lists.jboss.org/pipermail/hibernate-dev/attachments/20141202/ffc1ba52/attachment-0001.bin From sanne at hibernate.org Tue Dec 2 08:01:36 2014 From: sanne at hibernate.org (Sanne Grinovero) Date: Tue, 2 Dec 2014 13:01:36 +0000 Subject: [hibernate-dev] Maintenance on ci.hibernate.org In-Reply-To: <4B456883-34C3-4EE1-961E-D136645A9D21@hibernate.org> References: <4B456883-34C3-4EE1-961E-D136645A9D21@hibernate.org> Message-ID: On 2 December 2014 at 08:23, Emmanuel Bernard wrote: > The website returns "Service Unavailable?. > What is the expected downtime window? It was just Sunday afternoon, and I didn't do anything to restart it now after your first report so it seems to have returned by himself, or maybe you had something cached which needed to be invalidated as we upgraded a lot of components. (I did then later restart it to fix the two issues you reported right after). So if there are any more "Service Unavailable" please let me know. Sanne > >> On 01 Dec 2014, at 13:34, Davide D'Alto wrote: >> >> On a related note, >> I've also reinstalled couchdb since it stopped working for some reason. >> >> I've also changed the maven version used for hibernate-ogm-master-jdk9 to >> maven 3.2.3. >> Maven 3.2.3 fixes some some bugs related to the profiles activation. >> >> Davide >> >> >> On Sun, Nov 30, 2014 at 10:22 PM, Sanne Grinovero >> wrote: >> >>> All, >>> we needed to do some unplanned maintenance on ci.hibernate.org. >>> >>> At some point it was clear that we needed do deploy some significant >>> upgrades so while Davide fixed Apache HTTPD, I went ahead and updated >>> all of Jenkins plugins as well.. which I usually avoid to not need >>> checking all builds and integrations with external services, but this >>> time all validations would be needed anyway. >>> >>> So: >>> - I'm sorry if you received some false notifications from it. >>> - If some builds are now broken, it might need some reconfiguration. >>> - same for plugins configurations: I'm unable to double-check all >>> things you've all setup. >>> >>> Please let me know what isn't working anymore, or if you have a moment >>> to volunteer looking yourself that would be great. >>> >>> # Reminder >>> Anyone in the Hibernate organization on GitHub has configuration and >>> write permissions on this server; if you know what you're doing feel >>> free to take advantage of that but please always share a summary of >>> what you did / plan to do. >>> >>> Sanne >>> _______________________________________________ >>> hibernate-dev mailing list >>> hibernate-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > From emmanuel at hibernate.org Tue Dec 2 08:12:14 2014 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Tue, 2 Dec 2014 14:12:14 +0100 Subject: [hibernate-dev] org.hibernate.persister.spi.PersisterFactory and 5.0 In-Reply-To: References: Message-ID: >> Regarding the removal of Configuration in general, there will be some more >> work to be done in OGM. We have a custom sub-class, OgmConfiguration [3], >> which is used for two purposes: >> >> 1) Set some properties automatically (to enable OGM's naming strategy and >> query translator etc., use a specific mass indexer for Hibernate Search) >> > > These types of things would be done via the various bootstrap hooks. I say > "various" because there are multiple depending on what exactly you are > trying to achieve, each comes into play at different points in the > bootstrap process. Where do you think we should keep these needs. Maybe as subtasks of a ORM 5 issue, to make sure we don?t miss them? Gunnar, you are the (designated) man :) > > > >> 2) Provide an entry point into the API for setting store specific options, >> e.g. like so: >> >> OgmConfiguration ogmCfg = ...; >> ogmCfg.configureOptionsFor( MongoDB.class ) >> .entity( GolfPlayer.class ) >> .writeConcern( WriteConcernType.REPLICA_ACKNOWLEDGED ); >> > > This is akin to the bootstrap "builders" in ORM. The important point is to > think about where this fits logically in the bootstrap process. This is > the key differentiation between Configuration and this new bootstrap > approach. I don?t know when we need to do that but I think it would be useful to see how we could achieve extensibility or composability of the ORM builders to add Search or OGM specific building information That?s something that is still very blurry to me at this stage. From sanne at hibernate.org Tue Dec 2 08:13:58 2014 From: sanne at hibernate.org (Sanne Grinovero) Date: Tue, 2 Dec 2014 13:13:58 +0000 Subject: [hibernate-dev] Jandex 2.0 Beta - Java 8 Type Annotations, Generics, & Offline Reflection In-Reply-To: <20141202102950.GF20433@Sarmakand-4.lan> References: <20141201202423.GC20433@Sarmakand-4.lan> <20141202102950.GF20433@Sarmakand-4.lan> Message-ID: It looks awesome! but to be able to use it we also need to take these requirements in consideration: - users running in different containers than WildFly - users not running in any container at all - Hibernate Search integrators which are not based on ORM: running in WildFly but not having the benefit of an EntityManager based bootstrap where the container can "inject" a reference to the index; how do we get the index from the application server there? - integrators running anywhere (WildFly but not only) which today need to add new entity types "on the fly" at runtime (after the bootstrap was completed). I guess that's possible? We could also change one point dramatically: with Infinispan Query the reason for it to need adding new types "on the fly" is just because there is no reasonable solution for a full annotation scanning. But having this we might be able to simplify some code in Search by actually expecting to have a comprehensive list of types at bootstrap through Jandex, then we can remove some of the code to do "on the fly" type registration. I'm saying that we could remove some of the code because with dynamic types coming, we'll still want to make it possible to define new types dynamically.. so we wouldn't be able to remove all complexity but it still seems a good progress. Sanne On 2 December 2014 at 10:29, Hardy Ferentschik wrote: > Hi, > >> > In Search we have been talking for a long time to get rid of Commons >> > Annotations. It is basically already possible >> > now (using Jandex 1), but it got pushed back so far. Now with Jandex 2 we >> > definitely should make the switch. Maybe Search 5.1? >> > >> >> Out of interest, what would be the benefit for Search? > > Getting rid of Commons Annotations. That is a long standing task. The annotation > processing code could be simplified a fair bit in this case. > > The other advantage would be that in the case where Search is running in the container, > we could just take an existing Jandex index at bootstrap (instead of building one ourselves). > This would give a bit of boot speed-up. > >> > Last but not least Validator, there we have been talking about Jandex for >> > a while as well. The new version would not have >> > the benefit of being able to remove the dependency to classmate. >> >> I guess you mean it *would have* the benefit, right? > > sure :-) > >> Of course that comes at the price of adding another dependency, so that's >> not really an advantage per se for me :) > > Not per se, but we already talked about consuming a Jandex index as part of the > Bean Validation integration into Wildfly using CDI. In fact you seemed to be quite > keen back then to give it a go. Now we could do it without increasing the amount of > dependencies. > >> I think we should have a look at this Beta and provide feedback to Jason if >> > we find any problems. I am for sure to have a look >> > at it in the context of Validator. >> > >> >> I find being able to re-use the index generated by the application >> container very useful. It would give a nice performance boost out of the >> box when using HV on WildFly/EAP. > > Exactly. > >> The type annotation stuff may be useful, but it's not that this information >> cannot be accessed via reflection at all. There are known issues with >> corner cases, though. So Jandex may improve the situation for us. > > My hope is that code would be simpler by using a single library for doing all > reflection stuff including Java 8 type annotations, generic type resolution, etc > >> I'm asking to make sure we're on the same page regarding what we expect >> from using Jandex in terms of user-visible features/improvements. > > Right, this is not about adding new features for the user. The user might get some > speed-up and maybe less memory consumption, but otherwise we are talking about > internal changes. > > --Hardy > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From sanne at hibernate.org Tue Dec 2 09:24:58 2014 From: sanne at hibernate.org (Sanne Grinovero) Date: Tue, 2 Dec 2014 14:24:58 +0000 Subject: [hibernate-dev] Announcing a tandem maintenance release: Hibernate Search 4.4.6.Final and 4.5.2.Final Message-ID: Both versions Hibernate Search 4.4.6.Final and 4.5.2.Final are now available. I'm explaining the details and reasons here: http://in.relation.to/Bloggers/SomeExceptionalBackportsToMaintenanceHibernateSearchReleases Regards, Sanne From steve at hibernate.org Tue Dec 2 10:03:20 2014 From: steve at hibernate.org (Steve Ebersole) Date: Tue, 2 Dec 2014 09:03:20 -0600 Subject: [hibernate-dev] Jandex 2.0 Beta - Java 8 Type Annotations, Generics, & Offline Reflection In-Reply-To: References: <20141201202423.GC20433@Sarmakand-4.lan> <20141202102950.GF20433@Sarmakand-4.lan> Message-ID: I can't speak to Searchs or Validators use specifically, but Jandex is usable outside of WildFly. I know this through initially using Jandex on that metamodel work. Outside of WildFly, rather than being handed an index you would build an index. Pretty easy. See in-line wrt some of your specific requirements. On Tue, Dec 2, 2014 at 7:13 AM, Sanne Grinovero wrote: > It looks awesome! but to be able to use it we also need to take these > requirements in consideration: > - users running in different containers than WildFly > See above. > - users not running in any container at all > See above. > - Hibernate Search integrators which are not based on ORM: running in > WildFly but not having the benefit of an EntityManager based bootstrap > where the container can "inject" a reference to the index; how do we > get the index from the application server there? > Actually this is "problem" for non-JPA ORM use in WildFly too. The passing of the Jandex index is part of the JPA bootstrap process. I do not know of a way for a component to ask for a Jandex index itself aside from some code in WildFly pushing that to you. - integrators running anywhere (WildFly but not only) which today > need to add new entity types "on the fly" at runtime (after the > bootstrap was completed). > I am not fully grokking what you are saying here. You mention it below too. I think you are saying something like what Envers does: after all ORM mappings are known, Envers wants to add additional mappings (its versioned entities). Of course Envers is a bit different in that the additional metadata it adds is not annotation based, but xml based. But "expanding" a Jandex index is pretty easy because they can be composed/aggregated. > I guess that's possible? > > We could also change one point dramatically: with Infinispan Query the > reason for it to need adding new types "on the fly" is just because > there is no reasonable solution for a full annotation scanning. But > having this we might be able to simplify some code in Search by > actually expecting to have a comprehensive list of types at bootstrap > through Jandex, then we can remove some of the code to do "on the fly" > type registration. > I'm saying that we could remove some of the code because with dynamic > types coming, we'll still want to make it possible to define new types > dynamically.. so we wouldn't be able to remove all complexity but it > still seems a good progress. > Actually, one of Jandex's huge strengths is exactly this use case. The ability to "scan" for annotations. For example, ORM couldask Jandex for all uses of the @Entity annotation as a means to discover all annotated entities. Maybe I am misinterpreting your "no reasonable solution for a full annotation scanning" comment. Perhaps you mean in the non-WildFly-handed index case? In that non-WildFly-handed index case there is a question as to how you know what files to add to the index. Ideally, Jandex would cover the entire available ClassLoader. From steve at hibernate.org Tue Dec 2 10:06:00 2014 From: steve at hibernate.org (Steve Ebersole) Date: Tue, 2 Dec 2014 09:06:00 -0600 Subject: [hibernate-dev] Jandex 2.0 Beta - Java 8 Type Annotations, Generics, & Offline Reflection In-Reply-To: References: <20141201202423.GC20433@Sarmakand-4.lan> <20141202102950.GF20433@Sarmakand-4.lan> Message-ID: Forgot to mention, that it is even conceivable to have an optional build-time step that would allow users to pre-build the Jandex index for even faster startup in outside-of-WildFly use cases. A serialized form if you will. I want to investigate that in ORM. On Tue, Dec 2, 2014 at 9:03 AM, Steve Ebersole wrote: > I can't speak to Searchs or Validators use specifically, but Jandex is > usable outside of WildFly. I know this through initially using Jandex on > that metamodel work. Outside of WildFly, rather than being handed an index > you would build an index. Pretty easy. See in-line wrt some of your > specific requirements. > > > On Tue, Dec 2, 2014 at 7:13 AM, Sanne Grinovero > wrote: > >> It looks awesome! but to be able to use it we also need to take these >> requirements in consideration: >> - users running in different containers than WildFly >> > > See above. > > >> - users not running in any container at all >> > > See above. > > >> - Hibernate Search integrators which are not based on ORM: running in >> WildFly but not having the benefit of an EntityManager based bootstrap >> where the container can "inject" a reference to the index; how do we >> get the index from the application server there? >> > > Actually this is "problem" for non-JPA ORM use in WildFly too. The > passing of the Jandex index is part of the JPA bootstrap process. I do not > know of a way for a component to ask for a Jandex index itself aside from > some code in WildFly pushing that to you. > > - integrators running anywhere (WildFly but not only) which today >> need to add new entity types "on the fly" at runtime (after the >> bootstrap was completed). >> > > I am not fully grokking what you are saying here. You mention it below > too. I think you are saying something like what Envers does: after all ORM > mappings are known, Envers wants to add additional mappings (its versioned > entities). Of course Envers is a bit different in that the additional > metadata it adds is not annotation based, but xml based. But "expanding" a > Jandex index is pretty easy because they can be composed/aggregated. > > > >> I guess that's possible? >> >> We could also change one point dramatically: with Infinispan Query the >> reason for it to need adding new types "on the fly" is just because >> there is no reasonable solution for a full annotation scanning. But >> having this we might be able to simplify some code in Search by >> actually expecting to have a comprehensive list of types at bootstrap >> through Jandex, then we can remove some of the code to do "on the fly" >> type registration. > > >> I'm saying that we could remove some of the code because with dynamic >> types coming, we'll still want to make it possible to define new types >> dynamically.. so we wouldn't be able to remove all complexity but it >> still seems a good progress. >> > > > Actually, one of Jandex's huge strengths is exactly this use case. The > ability to "scan" for annotations. For example, ORM couldask Jandex for > all uses of the @Entity annotation as a means to discover all annotated > entities. Maybe I am misinterpreting your "no reasonable solution for a > full annotation scanning" comment. Perhaps you mean in the > non-WildFly-handed index case? In that non-WildFly-handed index case there > is a question as to how you know what files to add to the index. Ideally, > Jandex would cover the entire available ClassLoader. > > From hardy at hibernate.org Tue Dec 2 10:22:35 2014 From: hardy at hibernate.org (Hardy Ferentschik) Date: Tue, 2 Dec 2014 16:22:35 +0100 Subject: [hibernate-dev] Jandex 2.0 Beta - Java 8 Type Annotations, Generics, & Offline Reflection In-Reply-To: References: <20141201202423.GC20433@Sarmakand-4.lan> <20141202102950.GF20433@Sarmakand-4.lan> Message-ID: <20141202152235.GG20433@Sarmakand-4.lan> > We could also change one point dramatically: with Infinispan Query the > reason for it to need adding new types "on the fly" is just because > there is no reasonable solution for a full annotation scanning. But > having this we might be able to simplify some code in Search by > actually expecting to have a comprehensive list of types at bootstrap > through Jandex, then we can remove some of the code to do "on the fly" > type registration. Interesting idea. Something like this should be possible. --Hardy -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 496 bytes Desc: not available Url : http://lists.jboss.org/pipermail/hibernate-dev/attachments/20141202/5efb1b2f/attachment-0001.bin From hardy at hibernate.org Tue Dec 2 10:37:20 2014 From: hardy at hibernate.org (Hardy Ferentschik) Date: Tue, 2 Dec 2014 16:37:20 +0100 Subject: [hibernate-dev] Jandex 2.0 Beta - Java 8 Type Annotations, Generics, & Offline Reflection In-Reply-To: References: <20141201202423.GC20433@Sarmakand-4.lan> <20141202102950.GF20433@Sarmakand-4.lan> Message-ID: <20141202153720.GA22612@Sarmakand-4.local> On Tue, Dec 02, 2014 at 09:06:00AM -0600, Steve Ebersole wrote: > Forgot to mention, that it is even conceivable to have an optional > build-time step that would allow users to pre-build the Jandex index for > even faster startup in outside-of-WildFly use cases. A serialized form if > you will. I want to investigate that in ORM. Good idea. +1 --Hardy -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 496 bytes Desc: not available Url : http://lists.jboss.org/pipermail/hibernate-dev/attachments/20141202/d78378a5/attachment.bin From gbadner at redhat.com Wed Dec 3 00:34:24 2014 From: gbadner at redhat.com (Gail Badner) Date: Wed, 3 Dec 2014 00:34:24 -0500 (EST) Subject: [hibernate-dev] Mapping defaults for @OneToOne Message-ID: <26874588.22070924.1417584864378.JavaMail.zimbra@redhat.com> I'm a bit confused by the mapping defaults for @OneToOne defined in JPA 2.1. Sections 2.10.1 and 2.10.3.1 (Bidirectional and Unidirectional OneToOne Relationships) says, "The foreign key column has the same type as the primary key of table B and there is a unique key constraint on it." Section 11.1.41 (OneToOne Annotation) says that, by default, optional=true, which translates into nullable foreign key column(s). IIUC, the default mapping is not supported by many (all?) databases, because a constraint violation exception will be thrown if a column has a unique key constraint and there is more than one null value for that column. Currently, Hibernate does not create a unique key unless @OneToOne( optional=false ) is defined. I believe Hibernate is doing the right thing here, but it is not consistent with the spec. Is the spec wrong in this case, or am I missing something? Please let me know... Thanks, Gail From emmanuel at hibernate.org Wed Dec 3 03:29:07 2014 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Wed, 3 Dec 2014 09:29:07 +0100 Subject: [hibernate-dev] [website] Update your environment Message-ID: The dependencies for the hibernate.org website have changed. Make sure to get the latest from the production branch and run rake clean[all] rake setup Tested on Ruby 2.1.5 From gbadner at redhat.com Wed Dec 3 03:30:03 2014 From: gbadner at redhat.com (Gail Badner) Date: Wed, 3 Dec 2014 03:30:03 -0500 (EST) Subject: [hibernate-dev] Mapping defaults for @OneToOne In-Reply-To: <26874588.22070924.1417584864378.JavaMail.zimbra@redhat.com> References: <26874588.22070924.1417584864378.JavaMail.zimbra@redhat.com> Message-ID: <307326187.22143248.1417595403570.JavaMail.zimbra@redhat.com> In both of the following cases, Hibernate creates a unique key constraint: 1) 2) The documentation is clear that setting unique="true" indicates that a unique key constraint should be created. I only see mappings for in the documentation. Is the combination in 2) valid (unique="true" not-null="false")? ----- Original Message ----- > From: "Gail Badner" > To: "hibernate-dev" > Sent: Tuesday, December 2, 2014 9:34:24 PM > Subject: [hibernate-dev] Mapping defaults for @OneToOne > > I'm a bit confused by the mapping defaults for @OneToOne defined in JPA 2.1. > > Sections 2.10.1 and 2.10.3.1 (Bidirectional and Unidirectional OneToOne > Relationships) says, "The foreign key column has the same type as the > primary key of table B and there is a unique key constraint on it." > > Section 11.1.41 (OneToOne Annotation) says that, by default, optional=true, > which translates into nullable foreign key column(s). > > IIUC, the default mapping is not supported by many (all?) databases, because > a constraint violation exception will be thrown if a column has a unique key > constraint and there is more than one null value for that column. > > Currently, Hibernate does not create a unique key unless @OneToOne( > optional=false ) is defined. I believe Hibernate is doing the right thing > here, but it is not consistent with the spec. > > Is the spec wrong in this case, or am I missing something? Please let me > know... > > Thanks, > Gail > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From emmanuel at hibernate.org Wed Dec 3 03:33:50 2014 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Wed, 3 Dec 2014 09:33:50 +0100 Subject: [hibernate-dev] [ORM] Make EntityEntry and interface and have a Factory... or not Message-ID: <17DD9296-0DB7-4A71-BAA7-33AD4BD08A1B@hibernate.org> Back during the EntityEntry improvements, we explored the idea of an EntityEntryFactory and an EntityEntry interface so that one could provide alternative implementations optimized to the specific use case. We did not apply it in the 4.x branch possibly due to backward compatibility concerns. I did work on a version for master back in the days https://github.com/hibernate/hibernate-orm/pull/768 which got closed without being applied. So the question is, do we want that feature for ORM 5.0 or do we not want that feature? https://hibernate.atlassian.net/browse/HHH-9265 Emmanuel From hardy at hibernate.org Wed Dec 3 05:01:57 2014 From: hardy at hibernate.org (Hardy Ferentschik) Date: Wed, 3 Dec 2014 11:01:57 +0100 Subject: [hibernate-dev] [website] Update your environment In-Reply-To: References: Message-ID: <20141203100157.GB23306@Sarmakand-4.local> For what it's worth the update worked w/o problem for me using ruby-2.0.0 --Hardy On Wed, Dec 03, 2014 at 09:29:07AM +0100, Emmanuel Bernard wrote: > The dependencies for the hibernate.org website have changed. Make sure to get the latest from the production branch and run > > rake clean[all] > rake setup > > Tested on Ruby 2.1.5 > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 496 bytes Desc: not available Url : http://lists.jboss.org/pipermail/hibernate-dev/attachments/20141203/4b1e0c74/attachment.bin From sanne at hibernate.org Wed Dec 3 07:21:21 2014 From: sanne at hibernate.org (Sanne Grinovero) Date: Wed, 3 Dec 2014 12:21:21 +0000 Subject: [hibernate-dev] [ORM] Make EntityEntry and interface and have a Factory... or not In-Reply-To: <17DD9296-0DB7-4A71-BAA7-33AD4BD08A1B@hibernate.org> References: <17DD9296-0DB7-4A71-BAA7-33AD4BD08A1B@hibernate.org> Message-ID: I guess that's the same problem as raised by Andrej Golovnin: when master was renamed, all open PRs were automatically closed. +1 to reopen this one, I still want the feature ;) Sanne On 3 December 2014 at 08:33, Emmanuel Bernard wrote: > Back during the EntityEntry improvements, we explored the idea of an EntityEntryFactory and an EntityEntry interface so that one could provide alternative implementations optimized to the specific use case. > We did not apply it in the 4.x branch possibly due to backward compatibility concerns. > > I did work on a version for master back in the days https://github.com/hibernate/hibernate-orm/pull/768 which got closed without being applied. > So the question is, do we want that feature for ORM 5.0 or do we not want that feature? > https://hibernate.atlassian.net/browse/HHH-9265 > > Emmanuel > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From sanne at hibernate.org Wed Dec 3 07:30:44 2014 From: sanne at hibernate.org (Sanne Grinovero) Date: Wed, 3 Dec 2014 12:30:44 +0000 Subject: [hibernate-dev] Closed pull requests In-Reply-To: References: <84D5AADC-23D4-4377-AED7-1EB88869FF30@gmx.net> <7B4B4720-5C93-43C7-BDD8-F515CAA1A4F6@gmx.net> <32A4A57E-E639-4DB9-9079-E88BB301F0DD@gmx.net> Message-ID: Don't you all think it's very troubling that several issues in JIRA are marked as "resolved" but are not actually integrated in the new master? This query is probably not perfect but I hope it's enough to highlight the problem: https://hibernate.atlassian.net/issues/?filter=15161&jql=project%20%3D%20%22Hibernate%20ORM%22%20AND%20fixVersion%20%3D%206.0.0%20AND%20fixVersion%20not%20in%20(4.3.7%2C%204.3.6%2C%204.3.5%2C%204.3.4%2C%204.3.3%2C%204.3.2%2C%204.3.1)%20and%20status%20!%3D%20Open On 1 December 2014 at 23:31, Steve Ebersole wrote: > I am finishing up the initial 5.0 work for master right now. I will work > on these next. Ping me at the end of the week so I dont forget :) > > On Mon, Dec 1, 2014 at 3:07 PM, Andrej Golovnin wrote: > >> >> > They should get moved to the 4.3-based master. I think I found the >> relevant issues: >> > >> > * Oracle12cDialect - https://hibernate.atlassian.net/browse/HHH-9044 >> > * PostgreSQL92Dialect & PostgreSQL94Dialect - >> https://hibernate.atlassian.net/browse/HHH-9167 >> > >> > I have reopened them and targeted them for 5.0 >> >> Do you already know when they will get moved to the 4.3-based master? >> I think I should wait with my pull request until they get moved. > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From steve at hibernate.org Wed Dec 3 09:46:17 2014 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 3 Dec 2014 08:46:17 -0600 Subject: [hibernate-dev] Closed pull requests In-Reply-To: References: <84D5AADC-23D4-4377-AED7-1EB88869FF30@gmx.net> <7B4B4720-5C93-43C7-BDD8-F515CAA1A4F6@gmx.net> <32A4A57E-E639-4DB9-9079-E88BB301F0DD@gmx.net> Message-ID: Yes and no. The issues are closed *against 6.0*, which is still technically correct for the current state. The changes are still integrated into the metamodel branch which correlates to 6.0 in jira. The question is more *which* of those changes we want to migrate to master. On Wed, Dec 3, 2014 at 6:30 AM, Sanne Grinovero wrote: > Don't you all think it's very troubling that several issues in JIRA > are marked as "resolved" but are not actually integrated in the new > master? > > This query is probably not perfect but I hope it's enough to highlight > the problem: > > https://hibernate.atlassian.net/issues/?filter=15161&jql=project%20%3D%20%22Hibernate%20ORM%22%20AND%20fixVersion%20%3D%206.0.0%20AND%20fixVersion%20not%20in%20(4.3.7%2C%204.3.6%2C%204.3.5%2C%204.3.4%2C%204.3.3%2C%204.3.2%2C%204.3.1)%20and%20status%20!%3D%20Open > > > > On 1 December 2014 at 23:31, Steve Ebersole wrote: > > I am finishing up the initial 5.0 work for master right now. I will work > > on these next. Ping me at the end of the week so I dont forget :) > > > > On Mon, Dec 1, 2014 at 3:07 PM, Andrej Golovnin > wrote: > > > >> > >> > They should get moved to the 4.3-based master. I think I found the > >> relevant issues: > >> > > >> > * Oracle12cDialect - https://hibernate.atlassian.net/browse/HHH-9044 > >> > * PostgreSQL92Dialect & PostgreSQL94Dialect - > >> https://hibernate.atlassian.net/browse/HHH-9167 > >> > > >> > I have reopened them and targeted them for 5.0 > >> > >> Do you already know when they will get moved to the 4.3-based master? > >> I think I should wait with my pull request until they get moved. > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From steve at hibernate.org Wed Dec 3 09:48:20 2014 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 3 Dec 2014 08:48:20 -0600 Subject: [hibernate-dev] [ORM] Make EntityEntry and interface and have a Factory... or not In-Reply-To: References: <17DD9296-0DB7-4A71-BAA7-33AD4BD08A1B@hibernate.org> Message-ID: Well to be fair I have been pretty consistent in responding to all of these (on the dev ml, on irc, etc) to reopen the pull request if it was closed due to this and still should be applied. On Wed, Dec 3, 2014 at 6:21 AM, Sanne Grinovero wrote: > I guess that's the same problem as raised by Andrej Golovnin: when > master was renamed, all open PRs were automatically closed. > > +1 to reopen this one, I still want the feature ;) > > Sanne > > On 3 December 2014 at 08:33, Emmanuel Bernard > wrote: > > Back during the EntityEntry improvements, we explored the idea of an > EntityEntryFactory and an EntityEntry interface so that one could provide > alternative implementations optimized to the specific use case. > > We did not apply it in the 4.x branch possibly due to backward > compatibility concerns. > > > > I did work on a version for master back in the days > https://github.com/hibernate/hibernate-orm/pull/768 < > https://github.com/hibernate/hibernate-orm/pull/768> which got closed > without being applied. > > So the question is, do we want that feature for ORM 5.0 or do we not > want that feature? > > https://hibernate.atlassian.net/browse/HHH-9265 < > https://hibernate.atlassian.net/browse/HHH-9265> > > > > Emmanuel > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From sanne at hibernate.org Wed Dec 3 10:37:19 2014 From: sanne at hibernate.org (Sanne Grinovero) Date: Wed, 3 Dec 2014 15:37:19 +0000 Subject: [hibernate-dev] Closed pull requests In-Reply-To: References: <84D5AADC-23D4-4377-AED7-1EB88869FF30@gmx.net> <7B4B4720-5C93-43C7-BDD8-F515CAA1A4F6@gmx.net> <32A4A57E-E639-4DB9-9079-E88BB301F0DD@gmx.net> Message-ID: On 3 December 2014 at 14:46, Steve Ebersole wrote: > Yes and no. The issues are closed *against 6.0*, which is still technically > correct for the current state. The changes are still integrated into the > metamodel branch which correlates to 6.0 in jira. > > The question is more *which* of those changes we want to migrate to master. Ah thanks that clarifies. I was afraid you had plans to delete than branch. > > On Wed, Dec 3, 2014 at 6:30 AM, Sanne Grinovero wrote: >> >> Don't you all think it's very troubling that several issues in JIRA >> are marked as "resolved" but are not actually integrated in the new >> master? >> >> This query is probably not perfect but I hope it's enough to highlight >> the problem: >> >> https://hibernate.atlassian.net/issues/?filter=15161&jql=project%20%3D%20%22Hibernate%20ORM%22%20AND%20fixVersion%20%3D%206.0.0%20AND%20fixVersion%20not%20in%20(4.3.7%2C%204.3.6%2C%204.3.5%2C%204.3.4%2C%204.3.3%2C%204.3.2%2C%204.3.1)%20and%20status%20!%3D%20Open >> >> >> >> On 1 December 2014 at 23:31, Steve Ebersole wrote: >> > I am finishing up the initial 5.0 work for master right now. I will >> > work >> > on these next. Ping me at the end of the week so I dont forget :) >> > >> > On Mon, Dec 1, 2014 at 3:07 PM, Andrej Golovnin >> > wrote: >> > >> >> >> >> > They should get moved to the 4.3-based master. I think I found the >> >> relevant issues: >> >> > >> >> > * Oracle12cDialect - https://hibernate.atlassian.net/browse/HHH-9044 >> >> > * PostgreSQL92Dialect & PostgreSQL94Dialect - >> >> https://hibernate.atlassian.net/browse/HHH-9167 >> >> > >> >> > I have reopened them and targeted them for 5.0 >> >> >> >> Do you already know when they will get moved to the 4.3-based master? >> >> I think I should wait with my pull request until they get moved. >> > _______________________________________________ >> > hibernate-dev mailing list >> > hibernate-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > From gunnar at hibernate.org Wed Dec 3 16:59:44 2014 From: gunnar at hibernate.org (Gunnar Morling) Date: Wed, 3 Dec 2014 22:59:44 +0100 Subject: [hibernate-dev] [ORM] Make EntityEntry and interface and have a Factory... or not In-Reply-To: References: <17DD9296-0DB7-4A71-BAA7-33AD4BD08A1B@hibernate.org> Message-ID: > +1 to reopen this one, I still want the feature ;) Yes, it'd be nice to have, but do we really need it? For OGM the pluggable extra state is good enough for now I would say. Do you have a specific usage for a custom EE in mind? 2014-12-03 15:48 GMT+01:00 Steve Ebersole : > Well to be fair I have been pretty consistent in responding to all of these > (on the dev ml, on irc, etc) to reopen the pull request if it was closed > due to this and still should be applied. > > On Wed, Dec 3, 2014 at 6:21 AM, Sanne Grinovero > wrote: > > > I guess that's the same problem as raised by Andrej Golovnin: when > > master was renamed, all open PRs were automatically closed. > > > > +1 to reopen this one, I still want the feature ;) > > > > Sanne > > > > On 3 December 2014 at 08:33, Emmanuel Bernard > > wrote: > > > Back during the EntityEntry improvements, we explored the idea of an > > EntityEntryFactory and an EntityEntry interface so that one could provide > > alternative implementations optimized to the specific use case. > > > We did not apply it in the 4.x branch possibly due to backward > > compatibility concerns. > > > > > > I did work on a version for master back in the days > > https://github.com/hibernate/hibernate-orm/pull/768 < > > https://github.com/hibernate/hibernate-orm/pull/768> which got closed > > without being applied. > > > So the question is, do we want that feature for ORM 5.0 or do we not > > want that feature? > > > https://hibernate.atlassian.net/browse/HHH-9265 < > > https://hibernate.atlassian.net/browse/HHH-9265> > > > > > > Emmanuel > > > _______________________________________________ > > > hibernate-dev mailing list > > > hibernate-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From sanne at hibernate.org Fri Dec 5 15:30:01 2014 From: sanne at hibernate.org (Sanne Grinovero) Date: Fri, 5 Dec 2014 20:30:01 +0000 Subject: [hibernate-dev] Redefining the API/SPI/implementation split Message-ID: One of today's issues for Hibernate Search had the goal to move this class: org.hibernate.search.engine.spi.SearchFactoryImplementor to not have the "SPI" package postfix as we never meant this to be part of the SPI but rather an internal contract. While it's an internal contract, it's functionality is needed by other modules *in our same repository*, for example hibernate-search-orm needs to access it. So we consider it an integration contract across our own shards, but it's not meant to be used by anyone else. So it seemed a straight-forward decision to move it to: org.hibernate.search.engine.impl.SearchFactoryImplementor However then we need to patch the OSGi descriptor to export this package: org.hibernate.search.engine.impl By doing so this will export more than what is strictly necessary - as there are other classes in there - and this gets Karaf to blow up with many nasty errors as there are dependent classloaders being triggered by those other internal components. So we really need to keep those sealed into the module. So I was thinking to create a new package classification "internal": org.hibernate.search.engine.internal.SearchFactoryImplementor We would export this package via OSGi descriptors, but still the name should be self-explanatory enough as a warning to other consumers? Sanne From emmanuel at hibernate.org Fri Dec 5 16:35:36 2014 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Fri, 5 Dec 2014 22:35:36 +0100 Subject: [hibernate-dev] Redefining the API/SPI/implementation split In-Reply-To: References: Message-ID: <20141205213536.GA76338@hibernate.org> If hibernate-search-orm needs it, it's likely that infinispan-query could also make use of that contract. After all, infinispan-query is very similar conceptually to our ORM integration albeit simpler. Isn't it our definition of a SPI? If you don't change your mind, I am not a big fan of the internal name. If nothing because ORM uses it with a different semantic. I don't have very good alternatives - friend - sharedimpl Emmanuel On Fri 2014-12-05 20:30, Sanne Grinovero wrote: > One of today's issues for Hibernate Search had the goal to move this class: > > org.hibernate.search.engine.spi.SearchFactoryImplementor > > to not have the "SPI" package postfix as we never meant this to be > part of the SPI but rather an internal contract. > While it's an internal contract, it's functionality is needed by other > modules *in our same repository*, for example hibernate-search-orm > needs to access it. > So we consider it an integration contract across our own shards, but > it's not meant to be used by anyone else. > > So it seemed a straight-forward decision to move it to: > > org.hibernate.search.engine.impl.SearchFactoryImplementor > > However then we need to patch the OSGi descriptor to export this package: > org.hibernate.search.engine.impl > > By doing so this will export more than what is strictly necessary - as > there are other classes in there - and this gets Karaf to blow up with > many nasty errors as there are dependent classloaders being triggered > by those other internal components. So we really need to keep those > sealed into the module. > > So I was thinking to create a new package classification "internal": > > org.hibernate.search.engine.internal.SearchFactoryImplementor > > We would export this package via OSGi descriptors, but still the name > should be self-explanatory enough as a warning to other consumers? > > Sanne > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From sanne at hibernate.org Fri Dec 5 18:09:55 2014 From: sanne at hibernate.org (Sanne Grinovero) Date: Fri, 5 Dec 2014 23:09:55 +0000 Subject: [hibernate-dev] Redefining the API/SPI/implementation split In-Reply-To: <20141205213536.GA76338@hibernate.org> References: <20141205213536.GA76338@hibernate.org> Message-ID: Thanks for the quick feedback! On 5 December 2014 at 21:35, Emmanuel Bernard wrote: > If hibernate-search-orm needs it, it's likely that infinispan-query > could also make use of that contract. After all, infinispan-query is > very similar conceptually to our ORM integration albeit simpler. I had a similar thought, in fact I'm going through each and every use of these APIs by hibernate-search-ORM to see if it's really needed and cleaning up all those which can live with the proper SPI. By doing this, I'm "promoting" some method (one at the moment) from the Implementor to the proper SPI API. There are some cases though which are all of a)Required b)Highly ORM specialized c)Experimental And I don't feel comfortable exposing these on a clean SPI - nor I expect anyone to need them. Sometimes it's just convenience; we have an "util.JNDIHelper" which is needed in several modules (Massindexer statistics, JMS lookups, etc..) and I don't think we should expose it as an API nor that another project like Infinispan Query should ever use it. Also, Infinispan Query (and everyone else) can use the new "unwrap" method: at least accessing such experimental functionality would have a warning sign. > Isn't it our definition of a SPI? No. I just realised our definition of SPI isn't adequate as there are two different kinds of integration points. There is a remarkable difference in requirements between an SPI meant for "our own modules" (as in: versioned in the same repository) and one meant to be used/extended by a project which has an independent release cycle. - we can break our "internal" SPI in an atomic commit which also fixes all other modules so this never introduces compatibility problems - Running a single testsuite - with a single git checkout - immediately highlights if something is wrong - CI can prevent mistakes early on rather than the costly "revert after the release" process The way I previously understood our definition, the "SPI" is a rather stable contract meant for third party integrations, such as a second level cache for Hibernate (not all implementations live in the ORM source repository) or Infinispan Query / CapeDwarf integrating, so there is an expectation of stability there which we're not bound to for internal-only SPIs. Also I was expecting our "SPI" contract to be more stable than what we need across modules in the same repository; for example in the Infinispan Query case it's not desirable for me to keep all methods in mind which they use, nor having to run the Query testsuite on a Search snapshot every time I make a change to a method. The modules "owned" in the same repository don't have these drawbacks, so it can and should be treated differently. > If you don't change your mind, I am not a big fan of the internal name. > If nothing because ORM uses it with a different semantic. > I don't have very good alternatives > - friend > - sharedimpl My goal was to send the "keep away - here be monsters" kind of message but sounding a bit more professional, like an *internal implementation detail*. I don't see how the term "friend" helps? Also, anything is an "Implementation" so any "impl" postfix doesn't suggest at all that you should steer away from it.. "shared" making it worse :) How is "internal" different than the meaning ORM uses it for? Proposal: "private" ? At lest it will be familiar to Java visibility, but personally I still prefer the "internal". N.B. It's not a big deal how we call it as it's just an internal detail :-) Sanne > > Emmanuel > > On Fri 2014-12-05 20:30, Sanne Grinovero wrote: >> One of today's issues for Hibernate Search had the goal to move this class: >> >> org.hibernate.search.engine.spi.SearchFactoryImplementor >> >> to not have the "SPI" package postfix as we never meant this to be >> part of the SPI but rather an internal contract. >> While it's an internal contract, it's functionality is needed by other >> modules *in our same repository*, for example hibernate-search-orm >> needs to access it. >> So we consider it an integration contract across our own shards, but >> it's not meant to be used by anyone else. >> >> So it seemed a straight-forward decision to move it to: >> >> org.hibernate.search.engine.impl.SearchFactoryImplementor >> >> However then we need to patch the OSGi descriptor to export this package: >> org.hibernate.search.engine.impl >> >> By doing so this will export more than what is strictly necessary - as >> there are other classes in there - and this gets Karaf to blow up with >> many nasty errors as there are dependent classloaders being triggered >> by those other internal components. So we really need to keep those >> sealed into the module. >> >> So I was thinking to create a new package classification "internal": >> >> org.hibernate.search.engine.internal.SearchFactoryImplementor >> >> We would export this package via OSGi descriptors, but still the name >> should be self-explanatory enough as a warning to other consumers? >> >> Sanne >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev From steve at hibernate.org Sat Dec 6 11:02:38 2014 From: steve at hibernate.org (Steve Ebersole) Date: Sat, 6 Dec 2014 10:02:38 -0600 Subject: [hibernate-dev] Redefining the API/SPI/implementation split In-Reply-To: References: <20141205213536.GA76338@hibernate.org> Message-ID: > > Sometimes it's just convenience; we have an "util.JNDIHelper" which is > needed in several modules (Massindexer statistics, JMS lookups, etc..) > and I don't think we should expose it as an API nor that another > project like Infinispan Query should ever use it. > It's funny you bring up JNDIHelper specifically. ORM used to have a JNDIHelper class as well and I went through this same exercise. In ORM JNDIHelper is now the JndiService (I treat "well known acronyms" as words for the purpose of camel casing). But the important point is that it is a service, available from the service registry. To me, access to the service registries and their services overall, is an SPI concern. If some 3rd party integration wants to use Hibernate's JndiService as part of its integration (and some cache integrations do), I am more than ok with that. > > Isn't it our definition of a SPI? > > No. I just realised our definition of SPI isn't adequate as there are > two different kinds of integration points. > In my opinion we have many more "levels" of SPI then just 2. We have even discussed how to handle some of the differences a few times in f2f or irc. An SPI describes a contract meant for integration. But there are many parts to that. You mentioned caching, so the main contract there is the RegionFactory. So obviously an integrator is implementing that. The RegionFactory is returning Region instances. those 2 contracts need to remain stable. Since the integrations implement those contracts, any changes of any kind to the contracts require changes to the implementation (aside from certain cases involving supplied base implementations). Most of the methods on RegionFactory to build a Region accept a CacheDataDescription argument. CacheDataDescription is a "parameter object". Changes to CacheDataDescription do not generally require changes to the implementation. I like to think of it in terms of a component and the data passed between Hibernate and that component. So even though RegionFactorty, Region and CacheDataDescription are all "spi contracts", they fulfill very different roles in the concept of an SPI. Some need to be more stable than others. I also think a lot in terms of "audience" when it comes to contracts. I might write a class intending it for use by a number of different roles: 1. Another Hibernate class 1. In the same module 2. In another module 3. In another Hibernate project, although I prefer to think of this more in line with an "Integration" 2. Integration 1. As the contract for an integration 2. As the communication related to that integration 3. Application - SessionFactory, Session, etc Just wanted to clarify... Personally, I like the phrase "friend" or "family" when describing the type of thing you are discussing. Not sure either of those work great as a package name though to denote the idea of "stay away". From golovnin at gmx.net Sun Dec 7 16:13:34 2014 From: golovnin at gmx.net (Andrej Golovnin) Date: Sun, 7 Dec 2014 22:13:34 +0100 Subject: [hibernate-dev] Closed pull requests In-Reply-To: References: <84D5AADC-23D4-4377-AED7-1EB88869FF30@gmx.net> <7B4B4720-5C93-43C7-BDD8-F515CAA1A4F6@gmx.net> <32A4A57E-E639-4DB9-9079-E88BB301F0DD@gmx.net> Message-ID: <2BA028CE-12F2-45A4-B8CF-6EA74EF58C31@gmx.net> > On 02.12.2014, at 00:31, Steve Ebersole wrote: > > I am finishing up the initial 5.0 work for master right now. I will work on these next. Ping me at the end of the week so I dont forget :) Ping. :) > > On Mon, Dec 1, 2014 at 3:07 PM, Andrej Golovnin wrote: > > > They should get moved to the 4.3-based master. I think I found the relevant issues: > > > > * Oracle12cDialect - https://hibernate.atlassian.net/browse/HHH-9044 > > * PostgreSQL92Dialect & PostgreSQL94Dialect - https://hibernate.atlassian.net/browse/HHH-9167 > > > > I have reopened them and targeted them for 5.0 > > Do you already know when they will get moved to the 4.3-based master? > I think I should wait with my pull request until they get moved. > From sanne at hibernate.org Sun Dec 7 20:14:15 2014 From: sanne at hibernate.org (Sanne Grinovero) Date: Mon, 8 Dec 2014 01:14:15 +0000 Subject: [hibernate-dev] Redefining the API/SPI/implementation split In-Reply-To: References: <20141205213536.GA76338@hibernate.org> Message-ID: Thanks all, so I went for the "friend" package name, adding a brief notice in the javadocs. https://github.com/Sanne/hibernate-search/blob/HSEARCH-1739/engine/src/main/java/org/hibernate/search/engine/friend/package-info.java Sanne On 6 December 2014 at 16:02, Steve Ebersole wrote: >> Sometimes it's just convenience; we have an "util.JNDIHelper" which is >> needed in several modules (Massindexer statistics, JMS lookups, etc..) >> and I don't think we should expose it as an API nor that another >> project like Infinispan Query should ever use it. > > > It's funny you bring up JNDIHelper specifically. ORM used to have a > JNDIHelper class as well and I went through this same exercise. In ORM > JNDIHelper is now the JndiService (I treat "well known acronyms" as words > for the purpose of camel casing). But the important point is that it is a > service, available from the service registry. To me, access to the service > registries and their services overall, is an SPI concern. If some 3rd party > integration wants to use Hibernate's JndiService as part of its integration > (and some cache integrations do), I am more than ok with that. > > >> >> > Isn't it our definition of a SPI? >> >> No. I just realised our definition of SPI isn't adequate as there are >> two different kinds of integration points. > > > In my opinion we have many more "levels" of SPI then just 2. We have even > discussed how to handle some of the differences a few times in f2f or irc. > > An SPI describes a contract meant for integration. But there are many parts > to that. You mentioned caching, so the main contract there is the > RegionFactory. So obviously an integrator is implementing that. The > RegionFactory is returning Region instances. those 2 contracts need to > remain stable. Since the integrations implement those contracts, any > changes of any kind to the contracts require changes to the implementation > (aside from certain cases involving supplied base implementations). Most of > the methods on RegionFactory to build a Region accept a CacheDataDescription > argument. CacheDataDescription is a "parameter object". Changes to > CacheDataDescription do not generally require changes to the implementation. > I like to think of it in terms of a component and the data passed between > Hibernate and that component. So even though RegionFactorty, Region and > CacheDataDescription are all "spi contracts", they fulfill very different > roles in the concept of an SPI. Some need to be more stable than others. > > I also think a lot in terms of "audience" when it comes to contracts. I > might write a class intending it for use by a number of different roles: > > Another Hibernate class > > In the same module > In another module > In another Hibernate project, although I prefer to think of this more in > line with an "Integration" > > Integration > > As the contract for an integration > As the communication related to that integration > > Application - SessionFactory, Session, etc > > Just wanted to clarify... > > Personally, I like the phrase "friend" or "family" when describing the type > of thing you are discussing. Not sure either of those work great as a > package name though to denote the idea of "stay away". From emmanuel at hibernate.org Mon Dec 8 04:47:25 2014 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Mon, 8 Dec 2014 10:47:25 +0100 Subject: [hibernate-dev] Redefining the API/SPI/implementation split In-Reply-To: References: <20141205213536.GA76338@hibernate.org> Message-ID: <8E0CC093-45EA-43F3-8632-5AEA6B314D19@hibernate.org> After reading this thread, `family` or `private` feel better than `friend` BTW, can?t you isolate those classes in a dedicated package still marked `impl` but have it exposed to OSGi? After all all this "shared but not shared because we decided to cut our software in many pieces? is a bit of an implementation detail from a user PoV. > On 08 Dec 2014, at 02:14, Sanne Grinovero wrote: > > Thanks all, > so I went for the "friend" package name, adding a brief notice in the javadocs. > > https://github.com/Sanne/hibernate-search/blob/HSEARCH-1739/engine/src/main/java/org/hibernate/search/engine/friend/package-info.java > > Sanne > > On 6 December 2014 at 16:02, Steve Ebersole wrote: >>> Sometimes it's just convenience; we have an "util.JNDIHelper" which is >>> needed in several modules (Massindexer statistics, JMS lookups, etc..) >>> and I don't think we should expose it as an API nor that another >>> project like Infinispan Query should ever use it. >> >> >> It's funny you bring up JNDIHelper specifically. ORM used to have a >> JNDIHelper class as well and I went through this same exercise. In ORM >> JNDIHelper is now the JndiService (I treat "well known acronyms" as words >> for the purpose of camel casing). But the important point is that it is a >> service, available from the service registry. To me, access to the service >> registries and their services overall, is an SPI concern. If some 3rd party >> integration wants to use Hibernate's JndiService as part of its integration >> (and some cache integrations do), I am more than ok with that. >> >> >>> >>>> Isn't it our definition of a SPI? >>> >>> No. I just realised our definition of SPI isn't adequate as there are >>> two different kinds of integration points. >> >> >> In my opinion we have many more "levels" of SPI then just 2. We have even >> discussed how to handle some of the differences a few times in f2f or irc. >> >> An SPI describes a contract meant for integration. But there are many parts >> to that. You mentioned caching, so the main contract there is the >> RegionFactory. So obviously an integrator is implementing that. The >> RegionFactory is returning Region instances. those 2 contracts need to >> remain stable. Since the integrations implement those contracts, any >> changes of any kind to the contracts require changes to the implementation >> (aside from certain cases involving supplied base implementations). Most of >> the methods on RegionFactory to build a Region accept a CacheDataDescription >> argument. CacheDataDescription is a "parameter object". Changes to >> CacheDataDescription do not generally require changes to the implementation. >> I like to think of it in terms of a component and the data passed between >> Hibernate and that component. So even though RegionFactorty, Region and >> CacheDataDescription are all "spi contracts", they fulfill very different >> roles in the concept of an SPI. Some need to be more stable than others. >> >> I also think a lot in terms of "audience" when it comes to contracts. I >> might write a class intending it for use by a number of different roles: >> >> Another Hibernate class >> >> In the same module >> In another module >> In another Hibernate project, although I prefer to think of this more in >> line with an "Integration" >> >> Integration >> >> As the contract for an integration >> As the communication related to that integration >> >> Application - SessionFactory, Session, etc >> >> Just wanted to clarify... >> >> Personally, I like the phrase "friend" or "family" when describing the type >> of thing you are discussing. Not sure either of those work great as a >> package name though to denote the idea of "stay away". > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From hardy at hibernate.org Mon Dec 8 05:13:23 2014 From: hardy at hibernate.org (Hardy Ferentschik) Date: Mon, 8 Dec 2014 11:13:23 +0100 Subject: [hibernate-dev] Redefining the API/SPI/implementation split In-Reply-To: References: Message-ID: <20141208101323.GA69790@Sarmakand-4.local> Hi, > One of today's issues for Hibernate Search had the goal to move this class: > > org.hibernate.search.engine.spi.SearchFactoryImplementor Well, for me there is more to this than just moving. There are two issues imo. 1. The location. org.hibernate.search.engine.spi implies after our definition that it is and public SPI. However, according to Sanne it should not be private and the main/sole purpose of the class is to integrate the Search engine module with the orm module. 2. The name. SearchFactoryImplementor is something which implements SearchFactory. However, one of the latest changes was to make SearchFactory a stand alone class of the orm module. SearchFactory is now only available in the orm module and has not inheritance link anymore to SearchFactoryImplementor or SearchIntegrator. This is awesome, since now we are able to evolve the engine code in the direction for "free form" entities without affecting the API for the users using Search in combination with Hibernate ORM. However, it also means that the engine module should now be agnostic of the orm module. Having a SearchFactoryImplementor in the engine module, but the SearchFactory defined in the orm module seems wrong. So, what can be done? Similar to Emmanuel, I am against a internal/friend package. I think we should look at other things we can do. First off, I find the separation between SearchIntegrator (former SearchFactoryIntegrator) and SearchFactoryImplementor quite arbitrary. For example, the integrator contains getIndexBindings, whereas SearchFactoryImplemtor has a getIndexBindings. Why could the latter not be part of SearchIntegrator? If we move all methods of SearchFactoryImplementor into SearchIntegrator, and an integrator cannot implement all of them we could throw an OperationNotSupportedException. Other things we could do is to work with services. We could have something like a ORMInterationService which contains methods which are part of SearchFactoryImplemtor and which we don't want to move to SearchIntegrator. We could also keep SearchFactoryImplementor, but move it to the orm module. During bootstrapping in HibernateSearchSessionFactoryObserver we would create the SearchIntegrator and then wrapp/add the additional functionality required for the SearchFactoryImplementor. I think we would have a whole range of possibilities to address this. Just moving the class it imo not one of them. If we say that we don't have time to a full fledged refactoring (which would imo be a shame, since that was one of the targets of Search 5), I'd rather just rename the class for now and do a refactoring later. We could rename and deprecate the class to make clear that it is not an SPI. > So it seemed a straight-forward decision to move it to: > > org.hibernate.search.engine.impl.SearchFactoryImplementor > However then we need to patch the OSGi descriptor to export this package: > org.hibernate.search.engine.impl No, you cannot just move it to org.hibernate.search.engine.impl. If anything you would need to move it into a standalone impl package which does not contains any other class, say org.hibernate.search.engine.orm.impl. If you want to move the class, I'd rather do it this way than creating a 'friend' package. --Hardy -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 496 bytes Desc: not available Url : http://lists.jboss.org/pipermail/hibernate-dev/attachments/20141208/e6625f7e/attachment.bin From hardy at hibernate.org Mon Dec 8 05:18:19 2014 From: hardy at hibernate.org (Hardy Ferentschik) Date: Mon, 8 Dec 2014 11:18:19 +0100 Subject: [hibernate-dev] Redefining the API/SPI/implementation split In-Reply-To: <8E0CC093-45EA-43F3-8632-5AEA6B314D19@hibernate.org> References: <20141205213536.GA76338@hibernate.org> <8E0CC093-45EA-43F3-8632-5AEA6B314D19@hibernate.org> Message-ID: <20141208101819.GB69790@Sarmakand-4.local> Hi, On Mon, Dec 08, 2014 at 10:47:25AM +0100, Emmanuel Bernard wrote: > BTW, can?t you isolate those classes in a dedicated package still marked `impl` but have it exposed to OSGi? That was my suggestion as well. It is probably not the worst alternative. It moves the class out of the spi package and makes it an impl class (properly indicating that it is not to be used by anyone else). The downside is that we still need to expose this impl package via OSGi. However, since it would be a "dedicated" package just for this integration code, the impact would be minimal. Mind you, I still believe that we could address the whole issue in a much cleaner way as well. --Hardy -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 496 bytes Desc: not available Url : http://lists.jboss.org/pipermail/hibernate-dev/attachments/20141208/ab3e81ac/attachment.bin From sanne at hibernate.org Mon Dec 8 07:00:34 2014 From: sanne at hibernate.org (Sanne Grinovero) Date: Mon, 8 Dec 2014 12:00:34 +0000 Subject: [hibernate-dev] Redefining the API/SPI/implementation split In-Reply-To: <20141208101819.GB69790@Sarmakand-4.local> References: <20141205213536.GA76338@hibernate.org> <8E0CC093-45EA-43F3-8632-5AEA6B314D19@hibernate.org> <20141208101819.GB69790@Sarmakand-4.local> Message-ID: Ok that sounds like the best compromise. I'll adjust my open PR. Thanks! Sanne On 8 December 2014 at 10:18, Hardy Ferentschik wrote: > Hi, > > On Mon, Dec 08, 2014 at 10:47:25AM +0100, Emmanuel Bernard wrote: >> BTW, can?t you isolate those classes in a dedicated package still marked `impl` but have it exposed to OSGi? > > That was my suggestion as well. It is probably not the worst alternative. It moves the class out of the spi > package and makes it an impl class (properly indicating that it is not to be used by anyone else). > The downside is that we still need to expose this impl package via OSGi. However, since it would be a "dedicated" > package just for this integration code, the impact would be minimal. > > Mind you, I still believe that we could address the whole issue in a much cleaner way as well. > > --Hardy From sanne at hibernate.org Mon Dec 8 07:07:45 2014 From: sanne at hibernate.org (Sanne Grinovero) Date: Mon, 8 Dec 2014 12:07:45 +0000 Subject: [hibernate-dev] Redefining the API/SPI/implementation split In-Reply-To: <20141208101323.GA69790@Sarmakand-4.local> References: <20141208101323.GA69790@Sarmakand-4.local> Message-ID: On 8 December 2014 at 10:13, Hardy Ferentschik wrote: > Hi, > >> One of today's issues for Hibernate Search had the goal to move this class: >> >> org.hibernate.search.engine.spi.SearchFactoryImplementor > > Well, for me there is more to this than just moving. There are two issues imo. > > 1. The location. org.hibernate.search.engine.spi implies after our definition that it is > and public SPI. However, according to Sanne it should not be private and the main/sole > purpose of the class is to integrate the Search engine module with the orm module. s/ it should not be private/ it should be private/ > 2. The name. SearchFactoryImplementor is something which implements SearchFactory. However, > one of the latest changes was to make SearchFactory a stand alone class of the orm module. > SearchFactory is now only available in the orm module and has not inheritance link anymore > to SearchFactoryImplementor or SearchIntegrator. This is awesome, since now we are able > to evolve the engine code in the direction for "free form" entities without affecting the > API for the users using Search in combination with Hibernate ORM. However, it also means > that the engine module should now be agnostic of the orm module. Having a SearchFactoryImplementor > in the engine module, but the SearchFactory defined in the orm module seems wrong. Remember this still is "the implementor" for the SearchFactory API so the name is not wrong; what is wrong is the position in terms of modules. So while I disagree on a rename I agree on moving its role: in fact I've been working up to late tonight to move some things across modules; I had to back-off though as it's going to take me longer, and as long as we're clear this is not an SPI we an change it at any point. > > So, what can be done? Similar to Emmanuel, I am against a internal/friend package. I think we should > look at other things we can do. > > First off, I find the separation between SearchIntegrator (former SearchFactoryIntegrator) and > SearchFactoryImplementor quite arbitrary. For example, the integrator contains getIndexBindings, whereas > SearchFactoryImplemtor has a getIndexBindings. Why could the latter not be part of SearchIntegrator? > > If we move all methods of SearchFactoryImplementor into SearchIntegrator, and an integrator cannot > implement all of them we could throw an OperationNotSupportedException. > > Other things we could do is to work with services. We could have something like a ORMInterationService which > contains methods which are part of SearchFactoryImplemtor and which we don't want to move to > SearchIntegrator. > > We could also keep SearchFactoryImplementor, but move it to the orm module. During bootstrapping in > HibernateSearchSessionFactoryObserver we would create the SearchIntegrator and then wrapp/add the > additional functionality required for the SearchFactoryImplementor. +1 Makes a lot of sense but we need to postpone such internal refactorings by a couple of weeks. > I think we would have a whole range of possibilities to address this. Just moving the class it imo > not one of them. If we say that we don't have time to a full fledged refactoring (which would imo > be a shame, since that was one of the targets of Search 5), I'd rather just rename the class for now > and do a refactoring later. We could rename and deprecate the class to make clear that it is not an > SPI. Exactly I just want to rename things to "unclassify" it from SPI. > >> So it seemed a straight-forward decision to move it to: >> >> org.hibernate.search.engine.impl.SearchFactoryImplementor > >> However then we need to patch the OSGi descriptor to export this package: >> org.hibernate.search.engine.impl > > No, you cannot just move it to org.hibernate.search.engine.impl. If anything you would need to > move it into a standalone impl package which does not contains any other class, say > org.hibernate.search.engine.orm.impl. If you want to move the class, I'd rather do it this way > than creating a 'friend' package. > > --Hardy From hardy at hibernate.org Mon Dec 8 08:34:58 2014 From: hardy at hibernate.org (Hardy Ferentschik) Date: Mon, 8 Dec 2014 14:34:58 +0100 Subject: [hibernate-dev] Redefining the API/SPI/implementation split In-Reply-To: References: <20141208101323.GA69790@Sarmakand-4.local> Message-ID: <20141208133458.GD69790@Sarmakand-4.local> On Mon, Dec 08, 2014 at 12:07:45PM +0000, Sanne Grinovero wrote: > > 2. The name. SearchFactoryImplementor is something which implements SearchFactory. However, > > one of the latest changes was to make SearchFactory a stand alone class of the orm module. > > SearchFactory is now only available in the orm module and has not inheritance link anymore > > to SearchFactoryImplementor or SearchIntegrator. This is awesome, since now we are able > > to evolve the engine code in the direction for "free form" entities without affecting the > > API for the users using Search in combination with Hibernate ORM. However, it also means > > that the engine module should now be agnostic of the orm module. Having a SearchFactoryImplementor > > in the engine module, but the SearchFactory defined in the orm module seems wrong. > > Remember this still is "the implementor" for the SearchFactory API so > the name is not wrong; what is wrong is the position in terms of > modules. How can an interface be the "implementor" of anything. It just defines an API, it does not implement anything. This is exactly what I am saying, it is a misnomer to start with. --Hardy -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 496 bytes Desc: not available Url : http://lists.jboss.org/pipermail/hibernate-dev/attachments/20141208/24dbde51/attachment.bin From emmanuel at hibernate.org Mon Dec 8 09:31:13 2014 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Mon, 8 Dec 2014 15:31:13 +0100 Subject: [hibernate-dev] Redefining the API/SPI/implementation split In-Reply-To: <20141208133458.GD69790@Sarmakand-4.local> References: <20141208101323.GA69790@Sarmakand-4.local> <20141208133458.GD69790@Sarmakand-4.local> Message-ID: <01212969-C068-4CA5-A9F1-3C913299A66B@hibernate.org> > On 08 Dec 2014, at 14:34, Hardy Ferentschik wrote: > > On Mon, Dec 08, 2014 at 12:07:45PM +0000, Sanne Grinovero wrote: >>> 2. The name. SearchFactoryImplementor is something which implements SearchFactory. However, >>> one of the latest changes was to make SearchFactory a stand alone class of the orm module. >>> SearchFactory is now only available in the orm module and has not inheritance link anymore >>> to SearchFactoryImplementor or SearchIntegrator. This is awesome, since now we are able >>> to evolve the engine code in the direction for "free form" entities without affecting the >>> API for the users using Search in combination with Hibernate ORM. However, it also means >>> that the engine module should now be agnostic of the orm module. Having a SearchFactoryImplementor >>> in the engine module, but the SearchFactory defined in the orm module seems wrong. >> >> Remember this still is "the implementor" for the SearchFactory API so >> the name is not wrong; what is wrong is the position in terms of >> modules. > > How can an interface be the "implementor" of anything. It just defines an API, it does not implement > anything. This is exactly what I am saying, it is a misnomer to start with. It a contract of all implementors of SearchFactory, I don?t see anything wrong with the name. From sanne at hibernate.org Tue Dec 9 08:59:07 2014 From: sanne at hibernate.org (Sanne Grinovero) Date: Tue, 9 Dec 2014 13:59:07 +0000 Subject: [hibernate-dev] Hibernate Search 5.0.0 Candidate Release 1 Message-ID: Hello all, we've just released *CR1* of Hibernate Search 5.0 Please test it and let us know if we should go ahead with the final release, or if we have some more work to do. The release novelties are described at: http://in.relation.to/40742.lace Regards, Sanne From emmanuel at hibernate.org Wed Dec 10 14:46:22 2014 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Wed, 10 Dec 2014 20:46:22 +0100 Subject: [hibernate-dev] Hibernate OGM 4.1.0.CR1 - stable mapping Message-ID: <856C0041-3B90-42F5-89FD-A077120DE5A3@hibernate.org> After a huge push, we are now one release away from our Final version. So without further due, I present you Hibernate OGM 4.1.0.CR1. To sum it up: * stable mapping for each of the supported datastores (Infinispan, Ehcache, MongoDB, Neo4J) * new and better one cache per entity structure for key/value stores * improvement in Neo4J and MongoDB around embedded objects and composite ids * better documentation More at http://in.relation.to/Bloggers/HibernateOGM410CR1StableMapping Happy persisting Emmanuel From a.ajay.bhat at gmail.com Wed Dec 10 21:39:38 2014 From: a.ajay.bhat at gmail.com (Ajay Bhat) Date: Thu, 11 Dec 2014 02:39:38 +0000 Subject: [hibernate-dev] Starting contrib to Hibernate Message-ID: Hi all, I use Hibernate for persisting to databases at work, and I'd like to start contributing to Hibernate. Could i start with adding Google datastore as backend? Whats the status of this issue? Is there any other issue I could work on to get started? Thanks, Ajay https://hibernate.atlassian.net/browse/OGM-357?jql=project%20%3D%20OGM%20AND%20priority%20%3D%20Minor%20AND%20resolution%20%3D%20Unresolved%20AND%20assignee%20in%20(EMPTY)%20ORDER%20BY%20key%20DESC From emmanuel at hibernate.org Thu Dec 11 03:49:08 2014 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Thu, 11 Dec 2014 09:49:08 +0100 Subject: [hibernate-dev] Starting contrib to Hibernate In-Reply-To: References: Message-ID: Hi Ajay, I?m glad you are interested. You can certainly start working on the Google datastore if you want to. Do you have experience with it BTW? But that not necessary the easiest task to get started with.Otherwise, I have tagged more issues as suitable for contributors that we will need in the recent future. Look for that link https://hibernate.atlassian.net/browse/OGM-674?jql=project%20%3D%20OGM%20AND%20resolution%20%3D%20Unresolved%20AND%20%22Suitable%20for%20new%20contributors%22%20%3D%20%22Yes%2C%20likely%22%20ORDER%20BY%20fixVersion%20ASC and focus on the issues targeted for 4.1.next and 4.2 For example: https://hibernate.atlassian.net/browse/OGM-674 - remove empty nested documents from mongodb https://hibernate.atlassian.net/browse/OGM-614 -| support for new property types https://hibernate.atlassian.net/browse/OGM-401 -| https://hibernate.atlassian.net/browse/OGM-662 - Support replicas for MongoDB Thanks again ! Emmanuel > On 11 Dec 2014, at 03:39, Ajay Bhat wrote: > > Hi all, > I use Hibernate for persisting to databases at work, and I'd like to start > contributing to Hibernate. > > Could i start with adding Google datastore as backend? Whats the status of > this issue? Is there any other issue I could work on to get started? > > Thanks, > Ajay > > https://hibernate.atlassian.net/browse/OGM-357?jql=project%20%3D%20OGM%20AND%20priority%20%3D%20Minor%20AND%20resolution%20%3D%20Unresolved%20AND%20assignee%20in%20(EMPTY)%20ORDER%20BY%20key%20DESC > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From a.ajay.bhat at gmail.com Thu Dec 11 04:04:29 2014 From: a.ajay.bhat at gmail.com (Ajay Bhat) Date: Thu, 11 Dec 2014 09:04:29 +0000 Subject: [hibernate-dev] Starting contrib to Hibernate References: Message-ID: Hi Emmanuel, No I'm not familiar with the Google data store, but it looked like a good point to start, viz why I asked about it. Can you give me an idea of where in the code I ought to be looking to start on this? On Thu, Dec 11, 2014, 2:19 PM Emmanuel Bernard wrote: > Hi Ajay, > I?m glad you are interested. > > You can certainly start working on the Google datastore if you want to. Do > you have experience with it BTW? > > But that not necessary the easiest task to get started with.Otherwise, I > have tagged more issues as suitable for contributors that we will need in > the recent future. > > Look for that link > https://hibernate.atlassian.net/browse/OGM-674?jql=project%20%3D%20OGM%20AND%20resolution%20%3D%20Unresolved%20AND%20%22Suitable%20for%20new%20contributors%22%20%3D%20%22Yes%2C%20likely%22%20ORDER%20BY%20fixVersion%20ASC > > and focus on the issues targeted for 4.1.next and 4.2 > > For example: > https://hibernate.atlassian.net/browse/OGM-674 - remove empty nested > documents from mongodb > https://hibernate.atlassian.net/browse/OGM-614 -| support for new > property types > https://hibernate.atlassian.net/browse/OGM-401 -| > https://hibernate.atlassian.net/browse/OGM-662 - Support replicas for > MongoDB > > Thanks again ! > > Emmanuel > > On 11 Dec 2014, at 03:39, Ajay Bhat wrote: > > Hi all, > I use Hibernate for persisting to databases at work, and I'd like to start > contributing to Hibernate. > > Could i start with adding Google datastore as backend? Whats the status of > this issue? Is there any other issue I could work on to get started? > > Thanks, > Ajay > > > https://hibernate.atlassian.net/browse/OGM-357?jql=project%20%3D%20OGM%20AND%20priority%20%3D%20Minor%20AND%20resolution%20%3D%20Unresolved%20AND%20assignee%20in%20(EMPTY)%20ORDER%20BY%20key%20DESC > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > From steve at hibernate.org Thu Dec 11 16:41:09 2014 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 11 Dec 2014 15:41:09 -0600 Subject: [hibernate-dev] Mapping defaults for @OneToOne In-Reply-To: <717168605.26895163.1418331280099.JavaMail.zimbra@redhat.com> References: <26874588.22070924.1417584864378.JavaMail.zimbra@redhat.com> <824747432.26196596.1418239227481.JavaMail.zimbra@redhat.com> <717168605.26895163.1418331280099.JavaMail.zimbra@redhat.com> Message-ID: Are you asking me what "leveing rules" are? ANSI SQL defines a number of levels of conformance: entry, intermediate and full. These leveling rules describe additional rules/restrictions/limitations for certain conformance level. Taking a step back... a unique constraint says that the column(s) listed in the constraint specification must contain unique values. Well how do we know values are unique? We know because they are not equal to one another. And how does ANSI SQL define equality wrt NULL? It says that NULLs are never equal. So how can they violate a unique constraint? *If* we are to make any change here, I think what might be worthwhile is to have the Dialect indicate what level of conformance it suports wrt unique constraints. If the Dialect reports FULL or INTERMEDIATE support, then we would support building a UK on nullable columns; if it reports ENTRY, we would not. On Dec 11, 2014 2:54 PM, "Gail Badner" wrote: > I check several dialects (can't remember exactly which ones) > > I see the following in > http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt in 11.7 constraint definition>: > > Leveling Rules > > 1) The following restrictions apply for Intermediate SQL: > > None. > > 2) The following restrictions apply for Entry SQL in addition to > any Intermediate SQL restrictions: > > a) If PRIMARY KEY or UNIQUE is specified, then the defi- > nition> for each column whose is in the column list> shall specify NOT NULL. > > To be honest, I don't know how these leveling rules are supposed to work. > Do you? > > ----- Original Message ----- > > From: "Steve Ebersole" > > To: "Gail Badner" > > Sent: Wednesday, December 10, 2014 5:07:37 PM > > Subject: Re: [hibernate-dev] Mapping defaults for @OneToOne > > > > The point is the same. ANSI SQL even states that unique keys should > > disallow duplicate *non null* values but allow multiple rows with null. > > Again, it just makes sense; null is *not* a value. > > > > Does some database not support that? Yeah ok maybe > > On Dec 10, 2014 2:46 PM, "Gail Badner" wrote: > > > > > The problem here is not that the FK has a null value. The problem is > that > > > the FK column has a unique constraint. It's the unique constraint that > > > throws an exception when there is more than one null value for that > column. > > > > > > I chatted with Emmanuel about this topic: > > > > > > (01:26:57 PM) emmanuel: gbadner: BTW if that's about your email on -dev > > > and if for real DBs consider null as a unique value, then I think > Hibernate > > > doe sthr right thing by not enforcing > > > (01:26:59 PM) emmanuel: it > > > > > > (01:37:13 PM) gbadner: emmanuel, what does that mean wrt to the spec? > > > (01:37:37 PM) gbadner: is hibernate non-compliant, but does the right > > > thing? > > > (01:37:39 PM) emmanuel: the spec is not the gospel > > > (01:38:10 PM) gbadner: there is an inconsistency between hbm.xml and > > > annotations > > > (01:39:02 PM) gbadner: the reason I care is that I have a fix for an > issue > > > that works for annotations, but not hbm.xml > > > (01:39:34 PM) gbadner: the reason it works for annotations is because > > > there is no unique constraint when the @OneToOne is optional > > > (01:41:45 PM) gbadner: what *should* hibernate do when hbm.xml has: > > > not-null="false" unique="true" ? > > > (01:42:21 PM) emmanuel: hbm has always philosophically been close to > the > > > physicla model > > > (01:42:22 PM) gbadner: currently, hibernate goes ahead and creates the > > > unique constraint > > > (01:42:34 PM) emmanuel: so applying the unique constraint would be > what I > > > expect > > > (01:43:25 PM) gbadner: but should hibernate also override with > > > not-null="true" when unique="true"? > > > (01:44:03 PM) gbadner: ^^^ and give a warning? > > > (01:45:30 PM) emmanuel: gbadner: I don't think I would expect that from > > > hbm, no > > > (01:45:49 PM) emmanuel: afterall it might be applicable for some > database > > > (01:45:50 PM) emmanuel: s > > > (01:46:03 PM) emmanuel: (but even if it was not, hbm is explicit as I > > > mentioned) > > > (01:46:57 PM) gbadner: hibernate *knows* when a column is > non-nullable; I > > > don't think it knows when there is a unique constraint > > > (01:47:26 PM) gbadner: well, I suppose the best Hibernate can do is > just > > > assume there is a unique constraint > > > > > > My fix for HHH-9091 (really it's a hack) is not acceptable because it > will > > > cause regressions for hbm.xml mappings. > > > > > > HHH-9091 is caused by HHH-6484. HHH-6484 made a change to execute > orphan > > > deletes before anything else, which causes a regression as illustrated > in > > > > https://github.com/hibernate/hibernate-orm/commit/c068b6f70c84476db7a0cd26e80171ff69e51e90 > > > . > > > > > > At the very least, orphan-deletes must be executed in the proper > order. I > > > have to think more about whether are other dependencies that need to be > > > taken into account. > > > > > > I've had to put HHH-9091 on hold while I fix HHH-8401, but will need to > > > get back to it shortly. > > > > > > ----- Original Message ----- > > > > From: "Steve Ebersole" > > > > To: "Gail Badner" > > > > Sent: Wednesday, December 10, 2014 8:45:13 AM > > > > Subject: Re: [hibernate-dev] Mapping defaults for @OneToOne > > > > > > > > Actually, I would think databases would not treat null values in a FK > > > > column as being a constraint violation. Null is not a value. Do you > > > have > > > > specific details about that concretely? Databases I have worked > with do > > > > not behave that way. > > > > > > > > On Dec 2, 2014 11:34 PM, "Gail Badner" wrote: > > > > > > > > > > I'm a bit confused by the mapping defaults for @OneToOne defined > in JPA > > > > 2.1. > > > > > > > > > > Sections 2.10.1 and 2.10.3.1 (Bidirectional and Unidirectional > OneToOne > > > > Relationships) says, "The foreign key column has the same type as the > > > > primary key of table B and there is a unique key constraint on it." > > > > > > > > > > Section 11.1.41 (OneToOne Annotation) says that, by default, > > > > optional=true, which translates into nullable foreign key column(s). > > > > > > > > > > IIUC, the default mapping is not supported by many (all?) > databases, > > > > because a constraint violation exception will be thrown if a column > has a > > > > unique key constraint and there is more than one null value for that > > > column. > > > > > > > > > > Currently, Hibernate does not create a unique key unless @OneToOne( > > > > optional=false ) is defined. I believe Hibernate is doing the right > thing > > > > here, but it is not consistent with the spec. > > > > > > > > > > Is the spec wrong in this case, or am I missing something? Please > let > > > me > > > > know... > > > > > > > > > > Thanks, > > > > > Gail > > > > > _______________________________________________ > > > > > hibernate-dev mailing list > > > > > hibernate-dev at lists.jboss.org > > > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > > > > > > > > From steve at hibernate.org Thu Dec 11 19:05:43 2014 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 11 Dec 2014 18:05:43 -0600 Subject: [hibernate-dev] Mapping defaults for @OneToOne In-Reply-To: <1707521108.26952450.1418342217780.JavaMail.zimbra@redhat.com> References: <26874588.22070924.1417584864378.JavaMail.zimbra@redhat.com> <824747432.26196596.1418239227481.JavaMail.zimbra@redhat.com> <717168605.26895163.1418331280099.JavaMail.zimbra@redhat.com> <1707521108.26952450.1418342217780.JavaMail.zimbra@redhat.com> Message-ID: Well, we don't want to rely on that. That is meant to be across all features. I think we want to look at this for this specific feature. That's kind of the design of Dialect overall. On Dec 11, 2014 5:56 PM, "Gail Badner" wrote: > Yes, that makes good sense. I see the info is available via > DatabaseMetaData.supportsANSI92EntryLevelSQL(), > supportsANSI92IntermediateSQL(), and supportsANSI92FullSQL(). > > Hmm, what if DatabaseMetaData is not available. Do we assume ENTRY? > > ----- Original Message ----- > > From: "Steve Ebersole" > > To: "Gail Badner" , "hibernate-dev" < > hibernate-dev at lists.jboss.org> > > Sent: Thursday, December 11, 2014 1:41:09 PM > > Subject: Re: [hibernate-dev] Mapping defaults for @OneToOne > > > > Are you asking me what "leveing rules" are? ANSI SQL defines a number of > > levels of conformance: entry, intermediate and full. These leveling > rules > > describe additional rules/restrictions/limitations for certain > conformance > > level. > > > > Taking a step back... a unique constraint says that the column(s) listed > in > > the constraint specification must contain unique values. Well how do we > > know values are unique? We know because they are not equal to one > > another. And how does ANSI SQL define equality wrt NULL? It says that > > NULLs are never equal. So how can they violate a unique constraint? > > > > *If* we are to make any change here, I think what might be worthwhile is > to > > have the Dialect indicate what level of conformance it suports wrt unique > > constraints. If the Dialect reports FULL or INTERMEDIATE support, then > we > > would support building a UK on nullable columns; if it reports ENTRY, we > > would not. > > On Dec 11, 2014 2:54 PM, "Gail Badner" wrote: > > > > > I check several dialects (can't remember exactly which ones) > > > > > > I see the following in > > > http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt in 11.7 > > > constraint definition>: > > > > > > Leveling Rules > > > > > > 1) The following restrictions apply for Intermediate SQL: > > > > > > None. > > > > > > 2) The following restrictions apply for Entry SQL in addition > to > > > any Intermediate SQL restrictions: > > > > > > a) If PRIMARY KEY or UNIQUE is specified, then the > > defi- > > > nition> for each column whose is in the > > > column list> shall specify NOT NULL. > > > > > > To be honest, I don't know how these leveling rules are supposed to > work. > > > Do you? > > > > > > ----- Original Message ----- > > > > From: "Steve Ebersole" > > > > To: "Gail Badner" > > > > Sent: Wednesday, December 10, 2014 5:07:37 PM > > > > Subject: Re: [hibernate-dev] Mapping defaults for @OneToOne > > > > > > > > The point is the same. ANSI SQL even states that unique keys should > > > > disallow duplicate *non null* values but allow multiple rows with > null. > > > > Again, it just makes sense; null is *not* a value. > > > > > > > > Does some database not support that? Yeah ok maybe > > > > On Dec 10, 2014 2:46 PM, "Gail Badner" wrote: > > > > > > > > > The problem here is not that the FK has a null value. The problem > is > > > that > > > > > the FK column has a unique constraint. It's the unique constraint > that > > > > > throws an exception when there is more than one null value for that > > > column. > > > > > > > > > > I chatted with Emmanuel about this topic: > > > > > > > > > > (01:26:57 PM) emmanuel: gbadner: BTW if that's about your email on > -dev > > > > > and if for real DBs consider null as a unique value, then I think > > > Hibernate > > > > > doe sthr right thing by not enforcing > > > > > (01:26:59 PM) emmanuel: it > > > > > > > > > > (01:37:13 PM) gbadner: emmanuel, what does that mean wrt to the > spec? > > > > > (01:37:37 PM) gbadner: is hibernate non-compliant, but does the > right > > > > > thing? > > > > > (01:37:39 PM) emmanuel: the spec is not the gospel > > > > > (01:38:10 PM) gbadner: there is an inconsistency between hbm.xml > and > > > > > annotations > > > > > (01:39:02 PM) gbadner: the reason I care is that I have a fix for > an > > > issue > > > > > that works for annotations, but not hbm.xml > > > > > (01:39:34 PM) gbadner: the reason it works for annotations is > because > > > > > there is no unique constraint when the @OneToOne is optional > > > > > (01:41:45 PM) gbadner: what *should* hibernate do when hbm.xml has: > > > > > not-null="false" unique="true" ? > > > > > (01:42:21 PM) emmanuel: hbm has always philosophically been close > to > > > the > > > > > physicla model > > > > > (01:42:22 PM) gbadner: currently, hibernate goes ahead and creates > the > > > > > unique constraint > > > > > (01:42:34 PM) emmanuel: so applying the unique constraint would be > > > what I > > > > > expect > > > > > (01:43:25 PM) gbadner: but should hibernate also override with > > > > > not-null="true" when unique="true"? > > > > > (01:44:03 PM) gbadner: ^^^ and give a warning? > > > > > (01:45:30 PM) emmanuel: gbadner: I don't think I would expect that > from > > > > > hbm, no > > > > > (01:45:49 PM) emmanuel: afterall it might be applicable for some > > > database > > > > > (01:45:50 PM) emmanuel: s > > > > > (01:46:03 PM) emmanuel: (but even if it was not, hbm is explicit > as I > > > > > mentioned) > > > > > (01:46:57 PM) gbadner: hibernate *knows* when a column is > > > non-nullable; I > > > > > don't think it knows when there is a unique constraint > > > > > (01:47:26 PM) gbadner: well, I suppose the best Hibernate can do is > > > just > > > > > assume there is a unique constraint > > > > > > > > > > My fix for HHH-9091 (really it's a hack) is not acceptable because > it > > > will > > > > > cause regressions for hbm.xml mappings. > > > > > > > > > > HHH-9091 is caused by HHH-6484. HHH-6484 made a change to execute > > > orphan > > > > > deletes before anything else, which causes a regression as > illustrated > > > in > > > > > > > > > https://github.com/hibernate/hibernate-orm/commit/c068b6f70c84476db7a0cd26e80171ff69e51e90 > > > > > . > > > > > > > > > > At the very least, orphan-deletes must be executed in the proper > > > order. I > > > > > have to think more about whether are other dependencies that need > to be > > > > > taken into account. > > > > > > > > > > I've had to put HHH-9091 on hold while I fix HHH-8401, but will > need to > > > > > get back to it shortly. > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Steve Ebersole" > > > > > > To: "Gail Badner" > > > > > > Sent: Wednesday, December 10, 2014 8:45:13 AM > > > > > > Subject: Re: [hibernate-dev] Mapping defaults for @OneToOne > > > > > > > > > > > > Actually, I would think databases would not treat null values in > a FK > > > > > > column as being a constraint violation. Null is not a value. > Do you > > > > > have > > > > > > specific details about that concretely? Databases I have worked > > > with do > > > > > > not behave that way. > > > > > > > > > > > > On Dec 2, 2014 11:34 PM, "Gail Badner" > wrote: > > > > > > > > > > > > > > I'm a bit confused by the mapping defaults for @OneToOne > defined > > > in JPA > > > > > > 2.1. > > > > > > > > > > > > > > Sections 2.10.1 and 2.10.3.1 (Bidirectional and Unidirectional > > > OneToOne > > > > > > Relationships) says, "The foreign key column has the same type > as the > > > > > > primary key of table B and there is a unique key constraint on > it." > > > > > > > > > > > > > > Section 11.1.41 (OneToOne Annotation) says that, by default, > > > > > > optional=true, which translates into nullable foreign key > column(s). > > > > > > > > > > > > > > IIUC, the default mapping is not supported by many (all?) > > > databases, > > > > > > because a constraint violation exception will be thrown if a > column > > > has a > > > > > > unique key constraint and there is more than one null value for > that > > > > > column. > > > > > > > > > > > > > > Currently, Hibernate does not create a unique key unless > @OneToOne( > > > > > > optional=false ) is defined. I believe Hibernate is doing the > right > > > thing > > > > > > here, but it is not consistent with the spec. > > > > > > > > > > > > > > Is the spec wrong in this case, or am I missing something? > Please > > > let > > > > > me > > > > > > know... > > > > > > > > > > > > > > Thanks, > > > > > > > Gail > > > > > > > _______________________________________________ > > > > > > > hibernate-dev mailing list > > > > > > > hibernate-dev at lists.jboss.org > > > > > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > > > > > > > > > > > > > > > > > > > From emmanuel at hibernate.org Fri Dec 12 04:09:01 2014 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Fri, 12 Dec 2014 10:09:01 +0100 Subject: [hibernate-dev] Starting contrib to Hibernate In-Reply-To: References: Message-ID: Judging from the GAE datastore APIs, look at the mongodb module and in particular MongoDBDatastoreProvider which connects to the store and MongoDBDialect which really stores the tuples and associations. The MongoDBDialect is very complicated though because we do a lot of batching, you can also look at InfinispanDialect to better understand what?s going on. Emmanuel > On 11 Dec 2014, at 10:04, Ajay Bhat wrote: > > Hi Emmanuel, > No I'm not familiar with the Google data store, but it looked like a good point to start, viz why I asked about it. Can you give me an idea of where in the code I ought to be looking to start on this? > > On Thu, Dec 11, 2014, 2:19 PM Emmanuel Bernard > wrote: > Hi Ajay, > I?m glad you are interested. > > You can certainly start working on the Google datastore if you want to. Do you have experience with it BTW? > > But that not necessary the easiest task to get started with.Otherwise, I have tagged more issues as suitable for contributors that we will need in the recent future. > > Look for that link https://hibernate.atlassian.net/browse/OGM-674?jql=project%20%3D%20OGM%20AND%20resolution%20%3D%20Unresolved%20AND%20%22Suitable%20for%20new%20contributors%22%20%3D%20%22Yes%2C%20likely%22%20ORDER%20BY%20fixVersion%20ASC > and focus on the issues targeted for 4.1.next and 4.2 > > For example: > https://hibernate.atlassian.net/browse/OGM-674 - remove empty nested documents from mongodb > https://hibernate.atlassian.net/browse/OGM-614 -| support for new property types > https://hibernate.atlassian.net/browse/OGM-401 -| > https://hibernate.atlassian.net/browse/OGM-662 - Support replicas for MongoDB > > Thanks again ! > > Emmanuel > > >> On 11 Dec 2014, at 03:39, Ajay Bhat > wrote: >> > >> Hi all, >> I use Hibernate for persisting to databases at work, and I'd like to start >> contributing to Hibernate. >> >> Could i start with adding Google datastore as backend? Whats the status of >> this issue? Is there any other issue I could work on to get started? >> >> Thanks, >> Ajay >> >> https://hibernate.atlassian.net/browse/OGM-357?jql=project%20%3D%20OGM%20AND%20priority%20%3D%20Minor%20AND%20resolution%20%3D%20Unresolved%20AND%20assignee%20in%20(EMPTY)%20ORDER%20BY%20key%20DESC > >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > From hardy at hibernate.org Fri Dec 12 06:27:49 2014 From: hardy at hibernate.org (Hardy Ferentschik) Date: Fri, 12 Dec 2014 12:27:49 +0100 Subject: [hibernate-dev] Hibernate Search 5.0.0.CR2 released Message-ID: <20141212112749.GD11199@Sarmakand-4.local> Hi, not much more to say then $subject says. For more info check out in.relation.to - http://in.relation.to/41260.lace --Hardy -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 496 bytes Desc: not available Url : http://lists.jboss.org/pipermail/hibernate-dev/attachments/20141212/adc02069/attachment.bin From sanne at hibernate.org Fri Dec 12 09:02:11 2014 From: sanne at hibernate.org (Sanne Grinovero) Date: Fri, 12 Dec 2014 14:02:11 +0000 Subject: [hibernate-dev] Security: Requiring Maven version 3.2.3 in our (maven based) builds Message-ID: Some weeks ago there was quite a fuss about the security implications of Maven downloading all those binary jars over HTTP rather than over HTTPS. That was fixed and now all mirrors support HTTPS and this latest Maven version uses secure connections by default. I'm usually careful in upgrading Maven, but I've been using this version for a while now and it worked fine - including during release processes - and also it's the version used by CI since some weeks on some jobs (didn't update them all - CI can test with various different versions). I think we should make this version (at least) a requirement for builds. WDYT? Sanne From hardy at hibernate.org Fri Dec 12 09:10:20 2014 From: hardy at hibernate.org (Hardy Ferentschik) Date: Fri, 12 Dec 2014 15:10:20 +0100 Subject: [hibernate-dev] Security: Requiring Maven version 3.2.3 in our (maven based) builds In-Reply-To: References: Message-ID: <20141212141020.GG11199@Sarmakand-4.local> > I think we should make this version (at least) a requirement for builds. WDYT? Sure, why not. +1 --Hardy -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 496 bytes Desc: not available Url : http://lists.jboss.org/pipermail/hibernate-dev/attachments/20141212/73dcb76d/attachment.bin From vikas_bali at calypso.com Sat Dec 13 23:18:09 2014 From: vikas_bali at calypso.com (Vikas Bali) Date: Sun, 14 Dec 2014 04:18:09 +0000 Subject: [hibernate-dev] Remove added XML from confiuration Message-ID: Hi all I am having problem while adding mapping files dynamically. It takes long time to add after some time. I did not find any way to remove the added XML from configuration object once added. I believe this is an issue of performance. Please suggest. Thnaks Vikas From emmanuel at hibernate.org Tue Dec 16 09:01:08 2014 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Tue, 16 Dec 2014 15:01:08 +0100 Subject: [hibernate-dev] Help with Hibernate OGM-401 In-Reply-To: References: Message-ID: Hello, Look at BuiltInTypeTest and Bookmark. Bookmark hosts all of our built-in types. We usually don?t do unit tests in the strictest sense. We prefer to run the chain from top to bottom in what people call integration tests. About org.hibernate.ogm.test.type.CustomDateType org.hibernate.ogm.test.type.ExplodingType org.hibernate.ogm.test.type.OverridingTypeDialect org.hibernate.ogm.test.type.Poem They are testing that a dialect can override types. It is indeed a test and not part of the core engine. Emmanuel > On 16 Dec 2014, at 13:22, Ajay Bhat wrote: > > Hi Emmanuel, > > I was working on supporting Short and Float datatypes for Hibernate OGM (issue 401) and I noticed that there are no unit tests for TypeTranslatorImpl [1]. Where should I look for it, if a test does exist? Shall I add a unit test for that? > > Also I noticed that some classes are present in the "test" package, rather than "main".[2] Could you pls explain why this was done? > [1] org/hibernate/ogm/type/impl/TypeTranslatorImpl.java > [2] > org.hibernate.ogm.test.type.CustomDateType > org.hibernate.ogm.test.type.ExplodingType > org.hibernate.ogm.test.type.OverridingTypeDialect > org.hibernate.ogm.test.type.Poem > > https://hibernate.atlassian.net/browse/OGM-401 > > Thanks, > Ajay From a.ajay.bhat at gmail.com Wed Dec 17 07:37:58 2014 From: a.ajay.bhat at gmail.com (Ajay Bhat) Date: Wed, 17 Dec 2014 12:37:58 +0000 Subject: [hibernate-dev] Help with Hibernate OGM-401 References: Message-ID: I worked on the issue a bit and while doing tests I get this error in BuiltInTypeTest. I can't trace the source of the error. Could you pls help me out and point out where I'm going wrong here? I've linked relevant files in my forked repo. https://github.com/ajaybhat/hibernate-ogm/blob/testOGM-401/core/src/main/java/org/hibernate/ogm/type/impl/TypeTranslatorImpl.java https://github.com/ajaybhat/hibernate-ogm/blob/testOGM-401/core/src/test/java/org/hibernate/ogm/backendtck/type/BuiltInTypeTest.java https://github.com/ajaybhat/hibernate-ogm/blob/testOGM-401/core/src/test/java/org/hibernate/ogm/backendtck/type/Bookmark.java Error ===== Running org.hibernate.ogm.backendtck.type.BuiltInTypeTest Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 1.802 sec <<< FAILURE! testTypesSupport(org.hibernate.ogm.backendtck.type.BuiltInTypeTest) Time elapsed: 1.533 sec <<< ERROR! org.hibernate.PropertySetterAccessException: IllegalArgumentException occurred while calling setter for property [org.hibernate.ogm.backendtck.type.Bookmark.url Port (expected type = java.lang.Short)]; target = [org.hibernate.ogm.backendtck.type.Bookmark at 14590fe2], property value = [80] setter of org.hibernate.ogm.backe ndtck.type.Bookmark.urlPort at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:483) at org.hibernate.property.BasicPropertyAccessor$BasicSetter.set(BasicPropertyAccessor.java:68) at org.hibernate.tuple.entity.AbstractEntityTuplizer.setPropertyValues(AbstractEntityTuplizer.java:713) at org.hibernate.tuple.entity.PojoEntityTuplizer.setPropertyValues(PojoEntityTuplizer.java:362) at org.hibernate.persister.entity.AbstractEntityPersister.setPropertyValues(AbstractEntityPersister.java:4718) at org.hibernate.engine.internal.TwoPhaseLoad.doInitializeEntity(TwoPhaseLoad.java:188) at org.hibernate.engine.internal.TwoPhaseLoad.initializeEntity(TwoPhaseLoad.java:144) at org.hibernate.ogm.loader.impl.OgmLoader.initializeEntitiesAndCollections(OgmLoader.java:712) at org.hibernate.ogm.loader.impl.OgmLoader.doQuery(OgmLoader.java:358) at org.hibernate.ogm.loader.impl.OgmLoader.doQueryAndInitializeNonLazyCollections(OgmLoader.java:267) at org.hibernate.ogm.loader.impl.OgmLoader.loadEntity(OgmLoader.java:186) at org.hibernate.ogm.loader.impl.OgmLoader.load(OgmLoader.java:142) at org.hibernate.persister.entity.AbstractEntityPersister.load(AbstractEntityPersister.java:4126) at org.hibernate.event.internal.DefaultLoadEventListener.loadFromDatasource(DefaultLoadEventListener.java:503) at org.hibernate.event.internal.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:468) at org.hibernate.event.internal.DefaultLoadEventListener.load(DefaultLoadEventListener.java:213) at org.hibernate.event.internal.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:275) at org.hibernate.event.internal.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:151) at org.hibernate.internal.SessionImpl.fireLoad(SessionImpl.java:1070) at org.hibernate.internal.SessionImpl.access$2000(SessionImpl.java:176) at org.hibernate.internal.SessionImpl$IdentifierLoadAccessImpl.load(SessionImpl.java:2551) at org.hibernate.internal.SessionImpl.get(SessionImpl.java:955) at org.hibernate.engine.spi.SessionDelegatorBaseImpl.get(SessionDelegatorBaseImpl.java:661) at org.hibernate.ogm.backendtck.type.BuiltInTypeTest.testTypesSupport(BuiltInTypeTest.java:108) testStringMappedTypeSerialisation(org.hibernate.ogm.backendtck.type.BuiltInTypeTest) Time elapsed: 0.008 sec <<< ERROR! org.hibernate.ogm.exception.EntityAlreadyExistsException: OGM000067: Trying to insert an already existing entity: null at com.mongodb.CommandResult.getWriteException(CommandResult.java:88) at com.mongodb.CommandResult.getException(CommandResult.java:79) at com.mongodb.DBCollectionImpl.translateBulkWriteException(DBCollectionImpl.java:314) at com.mongodb.DBCollectionImpl.insert(DBCollectionImpl.java:189) at com.mongodb.DBCollectionImpl.insert(DBCollectionImpl.java:165) at com.mongodb.DBCollection.insert(DBCollection.java:161) at org.hibernate.ogm.datastore.mongodb.MongoDBDialect.flushInserts(MongoDBDialect.java:940) at org.hibernate.ogm.datastore.mongodb.MongoDBDialect.executeBatch(MongoDBDialect.java:841) at org.hibernate.ogm.dialect.impl.ForwardingGridDialect.executeBatch(ForwardingGridDialect.java:172) at org.hibernate.ogm.dialect.impl.BatchOperationsDelegator.executeBatch(BatchOperationsDelegator.java:73) at org.hibernate.ogm.service.impl.BatchManagerEventListener.onEvent(BatchManagerEventListener.java:42) at org.hibernate.ogm.service.impl.FlushBatchManagerEventListener.onFlush(FlushBatchManagerEventListener.java:29) at org.hibernate.internal.SessionImpl.flush(SessionImpl.java:1222) at org.hibernate.internal.SessionImpl.managedFlush(SessionImpl.java:425) at org.hibernate.ogm.transaction.impl.JTATransactionManagerTransaction.beforeTransactionCommit(JTATransactionManagerTransaction.java:94) at org.hibernate.engine.transaction.spi.AbstractTransactionImpl.commit(AbstractTransactionImpl.java:177) at org.hibernate.ogm.backendtck.type.BuiltInTypeTest.testStringMappedTypeSerialisation(BuiltInTypeTest.java:188) On Tue Dec 16 2014 at 7:31:25 PM Emmanuel Bernard wrote: > Hello, > > Look at BuiltInTypeTest and Bookmark. Bookmark hosts all of our built-in > types. > We usually don?t do unit tests in the strictest sense. We prefer to run > the chain from top to bottom in what people call integration tests. > > About > org.hibernate.ogm.test.type.CustomDateType > org.hibernate.ogm.test.type.ExplodingType > org.hibernate.ogm.test.type.OverridingTypeDialect > org.hibernate.ogm.test.type.Poem > > They are testing that a dialect can override types. It is indeed a test > and not part of the core engine. > > Emmanuel > > On 16 Dec 2014, at 13:22, Ajay Bhat wrote: > > Hi Emmanuel, > > I was working on supporting Short and Float datatypes for Hibernate OGM > (issue 401) and I noticed that there are no unit tests for > TypeTranslatorImpl [1]. Where should I look for it, if a test does exist? > Shall I add a unit test for that? > > Also I noticed that some classes are present in the "test" package, rather > than "main".[2] Could you pls explain why this was done? > [1] org/hibernate/ogm/type/impl/TypeTranslatorImpl.java > [2] > org.hibernate.ogm.test.type.CustomDateType > org.hibernate.ogm.test.type.ExplodingType > org.hibernate.ogm.test.type.OverridingTypeDialect > org.hibernate.ogm.test.type.Poem > > https://hibernate.atlassian.net/browse/OGM-401 > > Thanks, > Ajay > > > From emmanuel at hibernate.org Wed Dec 17 09:12:52 2014 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Wed, 17 Dec 2014 15:12:52 +0100 Subject: [hibernate-dev] Hibernate OGM 4.1 *Final* Message-ID: Today is a big day. The first release of Hibernate OGM with final status. Ever! Don't be fooled by the 4.1 number. Hibernate OGM is an object mapper for various NoSQL engines offering the familiar JPA APIs. This final version offers mapping for MongoDB, Neo4J, Infinispan and Ehcache. No more excuse to delay the download ;) More info at http://in.relation.to/Bloggers/FirstHibernateOGMReleaseAka41Final Emnmanuel From steve at hibernate.org Wed Dec 17 09:25:27 2014 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 17 Dec 2014 08:25:27 -0600 Subject: [hibernate-dev] Remove added XML from confiuration In-Reply-To: References: Message-ID: Can you explain better what exactly you are doing whe you say "adding mapping files dynamically"? Which specific method are you using? And then why are you wanting to remove them. I am confused. On Dec 13, 2014 10:19 PM, "Vikas Bali" wrote: > Hi all > > I am having problem while adding mapping files dynamically. It takes long > time to add after some time. I did not find any way to remove the added XML > from configuration object once added. I believe this is an issue of > performance. Please suggest. > > Thnaks > Vikas > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From sanne at hibernate.org Wed Dec 17 12:36:54 2014 From: sanne at hibernate.org (Sanne Grinovero) Date: Wed, 17 Dec 2014 17:36:54 +0000 Subject: [hibernate-dev] Hibernate Search 5.0.0.Final released! Message-ID: And on the same day as the first ever release of Hibernate OGM, we have a major release of Hibernate Search 5 as well! All details on the blog: http://in.relation.to/Bloggers/AFreshNewMajorReleaseHibernateSearch500Final Regards, Sanne From a.ajay.bhat at gmail.com Sun Dec 21 21:06:25 2014 From: a.ajay.bhat at gmail.com (Ajay Bhat) Date: Mon, 22 Dec 2014 02:06:25 +0000 Subject: [hibernate-dev] Need some help for new property types Message-ID: Hi, I was working on OGM-401 (Implementing new property types) and I encountered some errors while running the tests. I'd asked about it in the IRC, but since there wasn't anyone there at the time, I thought I'd ask around here. http://transcripts.jboss.org/channel/irc.freenode.org/%23hibernate-dev/2014/%23hibernate-dev.2014-12-21.log.html Thanks, Ajay From a.ajay.bhat at gmail.com Mon Dec 22 21:23:12 2014 From: a.ajay.bhat at gmail.com (Ajay Bhat) Date: Tue, 23 Dec 2014 02:23:12 +0000 Subject: [hibernate-dev] Need some help for new property types References: Message-ID: Thanks so much, Davide! Could you and/or the community review the below pull request? https://github.com/hibernate/hibernate-ogm/pull/461 On Mon Dec 22 2014 at 5:42:14 PM Davide D'Alto wrote: > Hi, > I gave a quick look at the patch, I think the reason it is not working > with MongoDB is that MongoDB does not support natively Character type. > > You need to use a different CharacterType implementation for MongoDB, you > can do it via the method MongoDBDialect.overrideType(...). You will find > that we are already doing it for other types like Byte and Calendar for > example. > You should do the same for Character (and Short I suspect). > > I have also created a branch where I rebased your work to the latest > changes and fixed the checktyle errors (branch 401 on my repository): > https://github.com/DavideD/hibernate-ogm/tree/OGM-401 > > I hope this help, > Davide > > On Mon, Dec 22, 2014 at 10:43 AM, Davide D'Alto > wrote: >> >> Hi Ajay, >> sorry we were quiet in these days, we worked hard for the latest OGM >> release and most of us have started the Christmas holidays. >> >> I'm packing for my holidays as well so I don't think I will be able to >> look at this now. >> I'll try to have a look at it tomorrow. >> >> Cheers, >> Davide >> >> >> On Mon, Dec 22, 2014 at 2:06 AM, Ajay Bhat wrote: >>> >>> Hi, >>> I was working on OGM-401 (Implementing new property types) and I >>> encountered some errors while running the tests. I'd asked about it in >>> the >>> IRC, but since there wasn't anyone there at the time, I thought I'd ask >>> around here. >>> >>> >>> http://transcripts.jboss.org/channel/irc.freenode.org/%23hibernate-dev/2014/%23hibernate-dev.2014-12-21.log.html >>> >>> Thanks, >>> Ajay >>> _______________________________________________ >>> hibernate-dev mailing list >>> hibernate-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> >> From a.ajay.bhat at gmail.com Tue Dec 23 04:04:15 2014 From: a.ajay.bhat at gmail.com (Ajay Bhat) Date: Tue, 23 Dec 2014 09:04:15 +0000 Subject: [hibernate-dev] OGM-317 : Establish profile for QA plug-ins Message-ID: Hi, I've created a PR [2] for the issue [1]. Please do review it [1] https://hibernate.atlassian.net/browse/OGM-317 [2] https://github.com/hibernate/hibernate-ogm/pull/462