And no, we generally do not reopen issues from Closed state. And here, given the different branches, I'd be more inclined to create a different issue referencing the original.
On Wed, Apr 1, 2015 at 6:18 AM, Steve Ebersole <st...@hibernate.org> wrote: > Hmm, it seems I inadvertently set the wrong fix version on HHH-8805. It > is fixed in our metamodel branch which is 6.0. I pulled the necessary > metamodel (org.hibernate.mapping) changes back to master (5.0), but only > the hbm.xml form of naming the FK "none" (magic value) is supported to > truly disable generation. For the time being you can use this as well from > annotations; just name the FK "none". > > If you can write some tests for this, it will make it easier for me to > implement. > > > > On Wed, Apr 1, 2015 at 5:40 AM, Petar Tahchiev <paranoia...@gmail.com> > wrote: > >> Oh, >> >> and one last thing: I don't think this is fixed: >> https://hibernate.atlassian.net/browse/HHH-8805 >> >> Here's my mapping: >> >> @ManyToMany(targetEntity = AbstractFilterModel.class, cascade = { >> CascadeType.PERSIST, >> CascadeType.MERGE, >> CascadeType.REFRESH >> }, fetch = FetchType.LAZY) >> @JoinTable(indexes = { >> @Index(unique = false, columnList = "entity_pk") >> }, inverseForeignKey = @ForeignKey(ConstraintMode.NO_CONSTRAINT), >> inverseJoinColumns = { >> @JoinColumn(unique = false, nullable = true, insertable = true, >> updatable = true, foreignKey = @ForeignKey(ConstraintMode.NO_CONSTRAINT), >> name = "filter_pk") >> }, joinColumns = { >> @JoinColumn(unique = false, nullable = true, insertable = true, >> updatable = true, foreignKey = @ForeignKey(ConstraintMode.NO_CONSTRAINT), >> name = "entity_pk") >> }, foreignKey = @ForeignKey(ConstraintMode.NO_CONSTRAINT), name = >> "entity_filters") >> private Collection<AbstractFilterModelDefinition> filters; >> >> As you can see I have added ConstraintMode.NO_CONSTRAINT wherever it is >> possible to add it. However here's what the schema tool generates: >> >> create index IDX8b6xl4emqmow8hikaf4hgx9xn on entity_filters >> (entity_pk); >> >> alter table entity_filters >> add constraint FKra38l70n01disvkge7i9ff5ym >> foreign key (filter_pk) >> references abstract_filter (pk); >> >> alter table entity_filters >> add constraint FKderx50xtd0lkeeblrj3o0ipq9 >> foreign key (entity_pk) >> references stock_level (pk); >> >> alter table entity_filters >> add constraint FK7ery3yx4pg32ogvv1wpr150oq >> foreign key (entity_pk) >> references content_slot (pk); >> >> alter table entity_filters >> add constraint FKse5m2mj7rrwj8ndimynfnr2px >> foreign key (entity_pk) >> references blog_entry (pk); >> >> alter table entity_filters >> add constraint FK9nubqtdhrmefjv2a5oab2fcr2 >> foreign key (entity_pk) >> references price (pk); >> >> alter table entity_filters >> add constraint FKcsuwqm524wu4u41oatrcalxvh >> foreign key (entity_pk) >> references tax (pk); >> >> alter table entity_filters >> add constraint FKmd3mm5pw9naa05ype38m6x1eo >> foreign key (entity_pk) >> references abstract_template (pk); >> >> alter table entity_filters >> add constraint FKsx6vnh2tga70pkne44dnq8kp0 >> foreign key (entity_pk) >> references discount (pk); >> >> alter table entity_filters >> add constraint FK6yx2wc1w1yb6qa1cx4byv7mju >> foreign key (entity_pk) >> references classification_feature (pk); >> >> alter table entity_filters >> add constraint FKpoh168do203hfqwb7so7c4c79 >> foreign key (entity_pk) >> references cms_navigation_node (pk); >> >> alter table entity_filters >> add constraint FKi85fkvbm7otl679ijlr6oyoff >> foreign key (entity_pk) >> references product (pk); >> >> alter table entity_filters >> add constraint FKi8semxf3lq0n12lm05v7oydeq >> foreign key (entity_pk) >> references abstract_page (pk); >> >> alter table entity_filters >> add constraint FKsjqo9a6quh1cg4y0wyqo4tp8b >> foreign key (entity_pk) >> references promotion (pk); >> >> alter table entity_filters >> add constraint FKfw64whfl6vgbqehj20qmc39i3 >> foreign key (entity_pk) >> references simple_cms_widget (pk); >> >> The foreign keys are all different (in Hibernate 4.3.x they were the >> same), but I just don't want them. Shall I reopen the issue? >> >> >> 2015-04-01 13:32 GMT+03:00 Petar Tahchiev <paranoia...@gmail.com>: >> >>> One other thing I noticed: >>> hibernate-core-5 depends on >>> >>> <groupId>org.jboss.logging</groupId> >>> <artifactId>jboss-logging</artifactId> >>> <version>3.2.1.Final</version> >>> >>> and if you have hibernate-validator 5.1.3.Final (the last stable), it >>> will depend on >>> >>> <groupId>org.jboss.logging</groupId> >>> <artifactId>jboss-logging</artifactId> >>> <version>3.1.4.GA</version> >>> >>> So you will get an exception of method not found on some jboss-logging >>> API. I excluded the jboss-loggin from the hibernate-validator >>> dependency, but now I get a ton of these TRACE statements (literally >>> every millisecond): >>> >>> 2015-04-01 13:28:02,090 >>> org.hibernate.event.internal.DefaultPersistEventListener >>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance >>> 2015-04-01 13:28:02,090 >>> org.hibernate.event.internal.DefaultPersistEventListener >>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance >>> 2015-04-01 13:28:02,090 >>> org.hibernate.event.internal.DefaultPersistEventListener >>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance >>> 2015-04-01 13:28:02,090 >>> org.hibernate.event.internal.DefaultPersistEventListener >>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance >>> 2015-04-01 13:28:02,090 >>> org.hibernate.event.internal.DefaultPersistEventListener >>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance >>> 2015-04-01 13:28:02,090 >>> org.hibernate.event.internal.DefaultPersistEventListener >>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance >>> 2015-04-01 13:28:02,090 >>> org.hibernate.event.internal.DefaultPersistEventListener >>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance >>> 2015-04-01 13:28:02,090 >>> org.hibernate.event.internal.DefaultPersistEventListener >>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance >>> 2015-04-01 13:28:02,090 >>> org.hibernate.event.internal.DefaultPersistEventListener >>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance >>> 2015-04-01 13:28:02,090 >>> org.hibernate.event.internal.DefaultPersistEventListener >>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance >>> 2015-04-01 13:28:02,090 >>> org.hibernate.event.internal.DefaultPersistEventListener >>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance >>> 2015-04-01 13:28:02,090 >>> org.hibernate.event.internal.DefaultPersistEventListener >>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance >>> 2015-04-01 13:28:02,090 >>> org.hibernate.event.internal.DefaultPersistEventListener >>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance >>> >>> >>> But at least it works.. I guess the only real solution is to have >>> hibernate-validator use the same jboss-logging version. >>> >>> >>> 2015-04-01 10:39 GMT+03:00 Gunnar Morling <gun...@hibernate.org>: >>> >>>> 2015-04-01 2:21 GMT+02:00 Steve Ebersole <st...@hibernate.org>: >>>> >>>> > Just to clarify... I *think* that as long as we run the build with >>>> Java 8 >>>> > and set the bootclasspath to 6 or 7 we should be fine. >>>> > >>>> >>>> Yes, setting the boot classpath to 6 (or 7) makes sure you only use >>>> classes >>>> present in that JDK (be it explicitly or implicitly as in the >>>> ConcurrentHashMap case), because it's that class library which will be >>>> used >>>> for compilation then. It is cumbersome to use though as you need to >>>> specify >>>> the location of a 6 or 7 JDK which makes the build less easily portable >>>> between machines. >>>> >>>> Currently, AnimalSniffer is in place to prevent this very category of >>>> error >>>> and I'm wondering why it didn't detect the "usage" of KeySetView. It >>>> really >>>> should have detected it, assuming it analyses the byte code of classes. >>>> But >>>> this makes me wonder now whether it only analyses the source code >>>> actually. >>>> Then it wouldn't be usable to prevent this sort of issue. >>>> >>>> Coding against the ConcurrentMap interface is the best way to avoid the >>>> issue. But of course there is no guarantee that it happens again, unless >>>> e.g. having a build on CI which uses 6 or 7 on its boot classpath. >>>> >>>> >>>> > On Tue, Mar 31, 2015 at 7:13 PM, Steve Ebersole <st...@hibernate.org> >>>> > wrote: >>>> > >>>> > > Well the idea is to run the Gradle process with Java 8 (the build >>>> itself >>>> > > is a Java process too don't forget). We pass in the older JDK >>>> > specifically >>>> > > to be able to set the bootclasspath for compilation and the >>>> executable >>>> > for >>>> > > running tests. That's the theory. >>>> > > >>>> > > Interestingly I developed a simplified project to test these >>>> theories: >>>> > > https://github.com/sebersole/gradle-mixed-jdk And of course this >>>> all >>>> > > works there. As you'd expect right? >>>> > > >>>> > > I think the JAXB thing comes into play here as well. Gradle does >>>> not >>>> > have >>>> > > any XJC support built in, so we have to make use of its Ant support >>>> to >>>> > run >>>> > > the XJC Ant tasks for JAXB model generation. The problem there is >>>> that, >>>> > > afaik, there is no way to tell Gradle's AntBuilder to use a JDK >>>> other >>>> > than >>>> > > the one that launched Gradle. I think this is why we see a JAXB >>>> model >>>> > > defined for Java 7, rather than Java 6, because we essentially run >>>> XJC >>>> > with >>>> > > Java 8. >>>> > > >>>> > > Anyway, this certainly makes the build more complex and we >>>> definitely >>>> > have >>>> > > to think through all these scenarios. In fact after Beta1, one of >>>> my >>>> > todos >>>> > > is to build up the build "from scratch" using that gradle-mixed-jdk >>>> > project >>>> > > as a basis. >>>> > > >>>> > > In general the plan though is to run all the tests (other than >>>> > > hibernate-java8, obviously) with the "baseline JDK, whether that be >>>> Java >>>> > 6 >>>> > > or 7. >>>> > > >>>> > > On Tue, Mar 31, 2015 at 6:59 PM, Sanne Grinovero < >>>> sa...@hibernate.org> >>>> > > wrote: >>>> > > >>>> > >> There are many similar issues discussed on the Lucene developer's >>>> > >> mailing list, it's an interesting read: >>>> > >> - >>>> > >> >>>> > >>>> http://mail-archives.apache.org/mod_mbox/lucene-dev/201503.mbox/%3C07c401d06aba%240b477c80%2421d67580%24%40thetaphi.de%3E >>>> > >> >>>> > >> I see no alternative than to have those test jobs actually >>>> exercising >>>> > >> ORM with JDK6, or maybe even compile it all with JDK6 except the >>>> Java8 >>>> > >> additional module to be compiled with JDK8 ? >>>> > >> >>>> > >> >>>> > >> >>>> > >> On 1 April 2015 at 00:36, Steve Ebersole <st...@hibernate.org> >>>> wrote: >>>> > >> > Ahh, seems this may be an option to work around it: >>>> > >> > >>>> > >> > <quote> >>>> > >> > Using the general *Map* interface in place of the concrete >>>> > >> > *ConcurrentHashMap* type here side-steps the coupling to the >>>> Java 8 >>>> > >> return >>>> > >> > type and will allow this code to be compiled with Java 8 and run >>>> on >>>> > >> Java 7. >>>> > >> > </quote> >>>> > >> > >>>> > >> > I had missed that part. >>>> > >> > >>>> > >> > >>>> > >> > On Tue, Mar 31, 2015 at 6:34 PM, Steve Ebersole < >>>> st...@hibernate.org> >>>> > >> wrote: >>>> > >> > >>>> > >> >> When I say "internal" here, I mean internal to java classes. >>>> > >> >> >>>> > >> >> On Tue, Mar 31, 2015 at 6:30 PM, Steve Ebersole < >>>> st...@hibernate.org >>>> > > >>>> > >> >> wrote: >>>> > >> >> >>>> > >> >>> Nope. It just effects any code compiled with Java 8 even >>>> though the >>>> > >> >>> change is internal. The problem is the generated bytecode >>>> > >> incorporates >>>> > >> >>> this change. Like I said, this should be compiled with 1.6 >>>> > >> compatibility, >>>> > >> >>> but that is apparently not working atm. I am having a struggle >>>> > >> getting a >>>> > >> >>> mixed JDK build working "just right". >>>> > >> >>> >>>> > >> >>> On Tue, Mar 31, 2015 at 6:28 PM, Petar Tahchiev < >>>> > >> paranoia...@gmail.com> >>>> > >> >>> wrote: >>>> > >> >>> >>>> > >> >>>> According to this: >>>> > >> >>>> >>>> > >> >>>> https://gist.github.com/AlainODea/1375759b8720a3f9f094 >>>> > >> >>>> >>>> > >> >>>> Notably the Java 1.7 *ConcurrentHashMap#keySet()* returns a >>>> Set<K> >>>> > >> while >>>> > >> >>>> the 1.8*ConcurrentHashMap#keySet()* returns a >>>> > >> >>>> ConcurrentHashMap.KeySetView<K,V>`. >>>> > >> >>>> >>>> > >> >>>> I think you're using some Java8 API. >>>> > >> >>>> >>>> > >> >>>> >>>> > >> >>>> 2015-04-01 2:25 GMT+03:00 Petar Tahchiev < >>>> paranoia...@gmail.com>: >>>> > >> >>>> >>>> > >> >>>>> petar@petar-ThinkPad-X1-Carbon:~$ java -version >>>> > >> >>>>> java version "1.7.0_71" >>>> > >> >>>>> Java(TM) SE Runtime Environment (build 1.7.0_71-b14) >>>> > >> >>>>> Java HotSpot(TM) 64-Bit Server VM (build 24.71-b01, mixed >>>> mode) >>>> > >> >>>>> petar@petar-ThinkPad-X1-Carbon:~$ uname -a >>>> > >> >>>>> Linux petar-ThinkPad-X1-Carbon 3.16.0-33-generic #44-Ubuntu >>>> SMP >>>> > Thu >>>> > >> Mar >>>> > >> >>>>> 12 12:19:35 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux >>>> > >> >>>>> petar@petar-ThinkPad-X1-Carbon:~$ >>>> > >> >>>>> >>>> > >> >>>>> >>>> > >> >>>>> 2015-04-01 2:21 GMT+03:00 Steve Ebersole < >>>> st...@hibernate.org>: >>>> > >> >>>>> >>>> > >> >>>>>> What JRE are you trying to use? This error: >>>> > >> >>>>>> >>>> > >> >>>>>> java.lang.NoSuchMethodError: java.util.concurrent. >>>> > >> >>>>>> ConcurrentHashMap.keySet()Ljava/util/concurrent/ >>>> > >> >>>>>> ConcurrentHashMap$KeySetView; >>>> > >> >>>>>> >>>> > >> >>>>>> is indicative of an issue in cross-jre support due to a >>>> change >>>> > >> >>>>>> internal to java classes. >>>> > >> >>>>>> >>>> > >> >>>>>> >>>> > >> >>>>>> On Tue, Mar 31, 2015 at 6:03 PM, Petar Tahchiev < >>>> > >> paranoia...@gmail.com >>>> > >> >>>>>> > wrote: >>>> > >> >>>>>> >>>> > >> >>>>>>> Thanks Steve, >>>> > >> >>>>>>> >>>> > >> >>>>>>> I managed to migrate my configuration to the new >>>> > >> >>>>>>> MetamodelImplementor. Now when I run the scema export I >>>> get a >>>> > lot >>>> > >> of these >>>> > >> >>>>>>> warning: >>>> > >> >>>>>>> >>>> > >> >>>>>>> INFO : HHH000400: Using dialect: >>>> > >> org.hibernate.dialect.MySQL5Dialect >>>> > >> >>>>>>> WARN : JDBC Driver reports it stores quoted identifiers in >>>> both >>>> > >> mixed >>>> > >> >>>>>>> and upper case >>>> > >> >>>>>>> WARN : HHH000072: Duplicate joins for class: >>>> > >> >>>>>>> com.xxx.platform.core.model.cms.AbstractPageModel >>>> > >> >>>>>>> WARN : HHH000072: Duplicate joins for class: >>>> > >> >>>>>>> com.xxx.platform.module.invoice.core.model.InvoicePageModel >>>> > >> >>>>>>> WARN : HHH000072: Duplicate joins for class: >>>> > >> >>>>>>> >>>> com.xxx.platform.core.model.batch.BatchStepExecutionContextModel >>>> > >> >>>>>>> WARN : HHH000072: Duplicate joins for class: >>>> > >> >>>>>>> >>>> com.xxx.platform.core.model.batch.BatchJobExecutionContextModel >>>> > >> >>>>>>> WARN : HHH000072: Duplicate joins for class: >>>> > >> >>>>>>> >>>> > >> >>>> com.xxx.platform.module.search.core.model.SearchKeywordRedirectModel >>>> > >> >>>>>>> WARN : HHH000072: Duplicate joins for class: >>>> > >> >>>>>>> >>>> > com.xxx.platform.module.search.core.model.SearchPageRedirectModel >>>> > >> >>>>>>> WARN : HHH000072: Duplicate joins for class: >>>> > >> >>>>>>> com.xxx.platform.module.promotion.core.model.PromotionModel >>>> > >> >>>>>>> >>>> > >> >>>>>>> and when I run some test I get the following exception: >>>> > >> >>>>>>> java.lang.NoSuchMethodError: >>>> > >> >>>>>>> >>>> > >> >>>> > >>>> java.util.concurrent.ConcurrentHashMap.keySet()Ljava/util/concurrent/ConcurrentHashMap$KeySetView; >>>> > >> >>>>>>> at >>>> > >> >>>>>>> >>>> > >> >>>> > >>>> org.hibernate.internal.SessionFactoryImpl.iterateEntityNameResolvers(SessionFactoryImpl.java:733) >>>> > >> >>>>>>> at >>>> > >> >>>>>>> >>>> > >> >>>> > >>>> org.hibernate.internal.SessionImpl$CoordinatingEntityNameResolver.resolveEntityName(SessionImpl.java:2470) >>>> > >> >>>>>>> at >>>> > >> >>>>>>> >>>> > >> >>>> > >>>> org.hibernate.internal.SessionImpl.guessEntityName(SessionImpl.java:1992) >>>> > >> >>>>>>> at >>>> > >> >>>>>>> >>>> > >> >>>> > >>>> org.hibernate.internal.SessionImpl.getEntityPersister(SessionImpl.java:1485) >>>> > >> >>>>>>> at >>>> > >> >>>>>>> >>>> > >> >>>> > >>>> org.hibernate.event.internal.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:163) >>>> > >> >>>>>>> at >>>> > >> >>>>>>> >>>> > >> >>>> > >>>> org.hibernate.event.internal.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:85) >>>> > >> >>>>>>> at >>>> > >> >>>>>>> >>>> > org.hibernate.internal.SessionImpl.fireMerge(SessionImpl.java:882) >>>> > >> >>>>>>> at >>>> > >> org.hibernate.internal.SessionImpl.merge(SessionImpl.java:864) >>>> > >> >>>>>>> at >>>> > >> org.hibernate.internal.SessionImpl.merge(SessionImpl.java:869) >>>> > >> >>>>>>> at >>>> > >> >>>>>>> >>>> > >> >>>> > >>>> org.hibernate.jpa.spi.AbstractEntityManagerImpl.merge(AbstractEntityManagerImpl.java:1196) >>>> > >> >>>>>>> at >>>> > >> >>>>>>> >>>> > >> >>>> > >>>> org.springframework.batch.item.database.JpaItemWriter.doWrite(JpaItemWriter.java:104) >>>> > >> >>>>>>> at >>>> > >> >>>>>>> >>>> > >> >>>> > >>>> org.springframework.batch.item.database.JpaItemWriter.write(JpaItemWriter.java:83) >>>> > >> >>>>>>> >>>> > >> >>>>>>> >>>> > >> >>>>>>> >>>> > >> >>>>>>> >>>> > >> >>>>>>> 2015-04-01 1:23 GMT+03:00 Steve Ebersole < >>>> st...@hibernate.org>: >>>> > >> >>>>>>> >>>> > >> >>>>>>>> I am told that the bug does not affect the JBoss->Central >>>> sync >>>> > >> >>>>>>>> process. So at some point the artifacts should all be >>>> > available >>>> > >> in Central >>>> > >> >>>>>>>> >>>> > >> >>>>>>>> On Tue, Mar 31, 2015 at 5:19 PM, Steve Ebersole < >>>> > >> st...@hibernate.org >>>> > >> >>>>>>>> > wrote: >>>> > >> >>>>>>>> >>>> > >> >>>>>>>>> hibernate-core seems to be the only artifact that is >>>> available >>>> > >> in >>>> > >> >>>>>>>>> JBoss Nexus. >>>> > >> >>>>>>>>> >>>> > >> >>>>>>>>> On Tue, Mar 31, 2015 at 5:18 PM, Steve Ebersole < >>>> > >> >>>>>>>>> st...@hibernate.org> wrote: >>>> > >> >>>>>>>>> >>>> > >> >>>>>>>>>> So apparently the artifacts / repo issue is a Nexus bug >>>> that >>>> > is >>>> > >> >>>>>>>>>> effecting the JBoss repo (and therefore us)... >>>> > >> >>>>>>>>>> http://issues.sonatype.org/browse/NEXUS-7654 >>>> > >> >>>>>>>>>> >>>> > >> >>>>>>>>>> As I pointed out in the announcement, I am managing the >>>> > >> "migration >>>> > >> >>>>>>>>>> guide" in source repo while I develop the Betas. See >>>> > >> >>>>>>>>>> >>>> > >> >>>> > >>>> https://github.com/hibernate/hibernate-orm/blob/master/working-5.0-migration-guide.md >>>> > >> >>>>>>>>>> As far are the new bootstrapping apis, see >>>> > >> >>>>>>>>>> >>>> > >> >>>> > >>>> http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/NativeBootstrapping.html >>>> > >> >>>>>>>>>> and >>>> > >> >>>>>>>>>> >>>> > >> >>>> > >>>> http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/LegacyBootstrapping.html >>>> > >> >>>>>>>>>> >>>> > >> >>>>>>>>>> On Tue, Mar 31, 2015 at 5:07 PM, Petar Tahchiev < >>>> > >> >>>>>>>>>> paranoia...@gmail.com> wrote: >>>> > >> >>>>>>>>>> >>>> > >> >>>>>>>>>>> Hi guys, >>>> > >> >>>>>>>>>>> >>>> > >> >>>>>>>>>>> I just tried the latest beta and I cannot compile my >>>> > project. >>>> > >> >>>>>>>>>>> With the >>>> > >> >>>>>>>>>>> latest hibernate 4.3.X I was able to do this: >>>> > >> >>>>>>>>>>> ------- >>>> > >> >>>>>>>>>>> final org.hibernate.cfg.Configuration >>>> configuration >>>> > = >>>> > >> >>>>>>>>>>> getHibernateConfiguration(); >>>> > >> >>>>>>>>>>> configuration.buildMappings(); >>>> > >> >>>>>>>>>>> final SchemaUpdate schemaUpdate = new >>>> > >> >>>>>>>>>>> SchemaUpdate(configuration); >>>> > >> >>>>>>>>>>> ------- >>>> > >> >>>>>>>>>>> >>>> > >> >>>>>>>>>>> however it seems that the SchemaUpdate constructor has >>>> been >>>> > >> >>>>>>>>>>> removed and now >>>> > >> >>>>>>>>>>> a new one is added: >>>> > >> >>>>>>>>>>> -------- >>>> > >> >>>>>>>>>>> public SchemaUpdate(MetadataImplementor metadata) { >>>> > >> >>>>>>>>>>> this( >>>> > >> >>>>>>>>>>> >>>> metadata.getMetadataBuildingOptions().getServiceRegistry(), >>>> > >> >>>>>>>>>>> metadata ); >>>> > >> >>>>>>>>>>> } >>>> > >> >>>>>>>>>>> --------- >>>> > >> >>>>>>>>>>> >>>> > >> >>>>>>>>>>> Also the configuration.buildMappings() method has been >>>> > >> >>>>>>>>>>> deprecated. Where do >>>> > >> >>>>>>>>>>> I get the MetadataImplementor from? Also is there any >>>> > >> changelog I >>>> > >> >>>>>>>>>>> can refer >>>> > >> >>>>>>>>>>> to? >>>> > >> >>>>>>>>>>> >>>> > >> >>>>>>>>>>> Thanks. >>>> > >> >>>>>>>>>>> -- >>>> > >> >>>>>>>>>>> Regards, Petar! >>>> > >> >>>>>>>>>>> Karlovo, Bulgaria. >>>> > >> >>>>>>>>>>> --- >>>> > >> >>>>>>>>>>> Public PGP Key at: >>>> > >> >>>>>>>>>>> >>>> > >> >>>>>>>>>>> >>>> > >> >>>> > >>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >>>> > >> >>>>>>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 >>>> 8550 >>>> > C311 >>>> > >> >>>>>>>>>>> 0611 >>>> > >> >>>>>>>>>>> _______________________________________________ >>>> > >> >>>>>>>>>>> hibernate-dev mailing list >>>> > >> >>>>>>>>>>> hibernate-dev@lists.jboss.org >>>> > >> >>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>> > >> >>>>>>>>>>> >>>> > >> >>>>>>>>>> >>>> > >> >>>>>>>>>> >>>> > >> >>>>>>>>> >>>> > >> >>>>>>>> >>>> > >> >>>>>>> >>>> > >> >>>>>>> >>>> > >> >>>>>>> -- >>>> > >> >>>>>>> Regards, Petar! >>>> > >> >>>>>>> Karlovo, Bulgaria. >>>> > >> >>>>>>> --- >>>> > >> >>>>>>> Public PGP Key at: >>>> > >> >>>>>>> >>>> > >> >>>> > >>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >>>> > >> >>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 >>>> C311 >>>> > >> 0611 >>>> > >> >>>>>>> >>>> > >> >>>>>> >>>> > >> >>>>>> >>>> > >> >>>>> >>>> > >> >>>>> >>>> > >> >>>>> -- >>>> > >> >>>>> Regards, Petar! >>>> > >> >>>>> Karlovo, Bulgaria. >>>> > >> >>>>> --- >>>> > >> >>>>> Public PGP Key at: >>>> > >> >>>>> >>>> > >> >>>> > >>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >>>> > >> >>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 >>>> C311 >>>> > 0611 >>>> > >> >>>>> >>>> > >> >>>> >>>> > >> >>>> >>>> > >> >>>> >>>> > >> >>>> -- >>>> > >> >>>> Regards, Petar! >>>> > >> >>>> Karlovo, Bulgaria. >>>> > >> >>>> --- >>>> > >> >>>> Public PGP Key at: >>>> > >> >>>> >>>> > >> >>>> > >>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >>>> > >> >>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 >>>> C311 0611 >>>> > >> >>>> >>>> > >> >>> >>>> > >> >>> >>>> > >> >> >>>> > >> > _______________________________________________ >>>> > >> > hibernate-dev mailing list >>>> > >> > hibernate-dev@lists.jboss.org >>>> > >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>> > >> >>>> > > >>>> > > >>>> > _______________________________________________ >>>> > hibernate-dev mailing list >>>> > hibernate-dev@lists.jboss.org >>>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>> > >>>> _______________________________________________ >>>> hibernate-dev mailing list >>>> hibernate-dev@lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>> >>> >>> >>> >>> -- >>> Regards, Petar! >>> Karlovo, Bulgaria. >>> --- >>> Public PGP Key at: >>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611 >>> >> >> >> >> -- >> Regards, Petar! >> Karlovo, Bulgaria. >> --- >> Public PGP Key at: >> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611 >> > > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
