Skip to content

Problems and Concerns with Unified Schema

Jump to bottom
Brett Meyer edited this page May 30, 2014 · 28 revisions

  • Mismatch in that hbm.xml did not require "mapped superclass" to be explicit. See tests in ehcache related to Item/VersionedItem as an example. This is an issue when we transform hbm mappings that map whose field/methods are on the superclass.

    One solution is to create the <mapped-superclass/> in these cases.

  • Not many unit tests directly use the new schema. Nearly all are still HBM and rely on the transformer. New tests need developed.

    The plan in my head is to complete the transformer, and then to code the build-time tasks and use it to transform all the existing HMB mappings; from there we would develop tests for specific problems with the tranformer.

  • Envers tests temporarily disabled under HHH-7490. See EnversJaxbRootProducer#addDocument and https://github.com/hibernate/hibernate-orm/commit/51d09c53cb2840bce4810657e33b6eea87bccddc#diff-5c01302b0d7f69715938704aa13e895cR162. There was still some ongoing discussion about what exactly Envers should provide. It's own jaxb bindings?

    Well the "problem" here is that Gail wanted to do this as an intermediate step where envers would produce HBM (either as DOM or as JAXB is really largely irrelevant). Ultimately I think envers should produce bindings as in org.hibernate.metamodel.spi.binding

  • OSGi tests temporarily disabled under HHH-9173. Will re-evaluate once core and entitymanager are in a better place.

    Hard to say, as you don't mention any specific problems

  • multiple mappings of the same class, using different entity names (HBM's concept of "entity name" in general isn't really supported by JPA) org.hibernate.test.idgen.enhanced.sequence.BasicSequenceTest#testSequencePerEntity() org.hibernate.test.loadplans.plans.LoadPlanStructureAssertionTest org.hibernate.test.mixed.MixedTest org.hibernate.test.optlock.OptimisticLockTest

    But the schema should support this. I made the /entity@class attribute optional in the unified schema (in JPA orm.xml xsd it is required). The XSD also has /entity@name attribute; the open question there being whether we can use this as the HBM entity name, or do we need a separate /entity@entity-name attribute?

  • extra laziness org.hibernate.metamodel.spi.binding.UnidirectionalManyToManyBindingTests org.hibernate.metamodel.spi.binding.basiccollections.HbmBasicCollectionBindingTests org.hibernate.metamodel.spi.binding.onetomany.HbmUnidirectionalOneToManyBindingTests org.hibernate.test.jpa.fetch.FetchingTest#testJoinedOneToOne()

    Open question as to how we want to expose this for mapping. I am not a fan of existing approach where this is essentially a "new" fetch mode. IMO, the fetch timing is delayed and the fetch strategy (how) is still open (SELECT, BATCH, SUBSELECT, etc). This concept of extra laziness is really an additional hint with regard to laziness and that we should be protective of initializing the entire collection. Therefore IMO this really should be a separate value.

  • New schema only defines batch-size at the class level, not collections. org.hibernate.test.batchfetch.BatchFetchTest org.hibernate.test.manytomany.batchload.BatchedManyToManyTest org.hibernate.test.version.db.DbVersionTest org.hibernate.test.where.WhereTest

    Yes it needs to be added to collections as well.

  • MultipleBagFetchException (bags appear to be transformed and mocked properly, so a bit confused about the cause) org.hibernate.test.cid.CompositeIdTest#testCompositeIds() org.hibernate.test.cid.CompositeIdTest#testMultipleCollectionFetch()

    That would indicate to me that they actually aren't bound properly, or maybe that Binder does not handle them properly.

  • formulas as map keys org.hibernate.test.collection.map.PersistentMapTest org.hibernate.test.extralazy.ExtraLazyTest org.hibernate.test.joinfetch.JoinFetchTest org.hibernate.test.map.MapIndexFormulaTest

    Yes we need to add support for this. Its missing in the schema. Is it supported in annotations?

  • association formulas org.hibernate.test.jpa.fetch.FetchingTest#testSpecialOneToOne() org.hibernate.test.loadplans.process.NonEncapsulatedCompositeIdResultSetProcessorTest org.hibernate.test.loadplans.walking.KeyManyToOneWalkingTest org.hibernate.test.manytomany.ManyToManyTest org.hibernate.test.mapelemformula.MapElementFormulaTest org.hibernate.test.onetoone.formula.OneToOneFormulaTest org.hibernate.test.typedmanytoone.TypedManyToOneTest org.hibernate.test.unconstrained.UnconstrainedTest

    Need to think through this one..

    BRETT (from old notes): (02:51:13 PM) sebersole: brmeyer1: i think this is one of the "extension points" that needs done. aka, a @PrimaryKeyJoinColumnsOrFormulas (02:51:45 PM) sebersole: similar to our @JoinColumnsOrFormulas

  • EntityMode.MAP org.hibernate.test.entitymode.map.basic.DynamicClassTest org.hibernate.test.legacy.MapTest org.hibernate.test.onetoone.nopojo.DynamicMapOneToOneTest org.hibernate.test.tm.CMTTest

    This needs to work, and mostly should work. I'll need to look through the failures to see where it breaks down. Do you map them to "annotations"? That part is much the same as the deal above wrt entity-name.

  • appears using component.field as the association path is failing org.hibernate.test.fetchprofiles.join.JoinFetchProfileTest

    Need to look at failure...

  • <filter> within a collection org.hibernate.test.filter.DynamicFilterTest org.hibernate.test.subclassfilter.DiscrimSubclassFilterTest

  • joined subclass not receiving columns defined by superclass org.hibernate.test.filter.hql.JoinedFilteredBulkManipulationTest#testFilteredJoinedSubclassHqlDeleteLeaf() org.hibernate.test.filter.hql.JoinedFilteredBulkManipulationTest#testFilteredJoinedSubclassHqlDeleteNonLeaf() org.hibernate.test.filter.hql.JoinedFilteredBulkManipulationTest#testFilteredJoinedSubclassHqlUpdateLeaf() org.hibernate.test.filter.hql.JoinedFilteredBulkManipulationTest#testFilteredJoinedSubclassHqlUpdateNonLeaf()

  • joined subclass not receiving filters defined by superclass org.hibernate.test.subclassfilter.JoinedSubclassFilterTest

  • null rows attempted on secondary table, even though optional is handled in EntityMocker org.hibernate.test.onetoone.link.OneToOneLinkTest

  • with optional=true. If it's a simple @SecondaryTable, that's easy enough -- Hibernate @Table w/ optional=true and appliesTo. But something like this is also possible: https://gist.github.com/brmeyer/afac86cfaa6fac3232bf. If the is optional, but the table's owning side is not a @SecondaryTable ( with a typical join table, and therefore no optional attribute), I'm not sure of the best way to resolve that. Ie, if the inverse use of the secondary table is optional, but the owning side doesn't have it set, how to handle? Note that I added an optional attribute to the schema's secondary-table, but not sure if that was correct. org.hibernate.test.immutable.entitywithmutablecollection.noninverse.EntityWithNonInverseOneToManyJoinTest org.hibernate.test.immutable.entitywithmutablecollection.inverse.VersionedEntityWithInverseOneToManyJoinFailureExpectedTest org.hibernate.test.immutable.entitywithmutablecollection.noninverse.VersionedEntityWithNonInverseOneToManyJoinTest

  • The following all use variations of the same mapping, but it seems really off. Ex: Many of the classes have an inverse w/ a but the Info class has no associations, Contract#parties should probably be inverse, etc. Re-evaluate the whole mapping. org.hibernate.test.immutable.entitywithmutablecollection.inverse.EntityWithInverseManyToManyTest org.hibernate.test.immutable.entitywithmutablecollection.inverse.VersionedEntityWithInverseManyToManyTest org.hibernate.test.immutable.entitywithmutablecollection.noninverse.EntityWithNonInverseManyToManyTest org.hibernate.test.immutable.entitywithmutablecollection.noninverse.EntityWithNonInverseOneToManyTest org.hibernate.test.immutable.entitywithmutablecollection.noninverse.VersionedEntityWithNonInverseManyToManyTest org.hibernate.test.immutable.entitywithmutablecollection.noninverse.VersionedEntityWithNonInverseOneToManyTest

  • mapping looks off: Membership and subclass have Serializable id, but mapping uses type=long org.hibernate.test.manytomanyassociationclass.surrogateid.generated.ManyToManyAssociationClassGeneratedIdTest

  • metamodel doesn't appear to be able to handle the composite-id key-many-to-one's on-delete (translated to @OnDelete) org.hibernate.test.keymanytoone.unidir.ondelete.KeyManyToOneCascadeDeleteTest

  • many-to-* w/ orphan removal org.hibernate.test.orphan.manytomany.ManyToManyOrphanTest org.hibernate.test.orphan.one2one.fk.composite.DeleteOneToOneOrphansTest org.hibernate.test.orphan.one2one.fk.reversed.unidirectional.DeleteOneToOneOrphansTest#testOrphanedWhileManaged() org.hibernate.test.orphan.one2one.fk.reversed.unidirectional.DeleteOneToOneOrphansTest#testReplacedWhileManaged()

    Probably many-to* here is a misnomer. Not all many-to-* support orphan removal; only collections and one-to-one.

  • for some reason, the SF statistics are off -- not sure if it's due to insertable/updatable, cascading, etc., all of which are working elsewhere org.hibernate.test.readonly.ReadOnlyVersionedNodesTest#*

  • named query return-join org.hibernate.test.resulttransformer.ResultTransformerTest

    Yeah, this is missing; JPA does not support this in result-set-mapping. We'll need to add

  • <import> is in the schema, but not mocked -- how to handle within annotations? org.hibernate.test.stats.StatsTest org.hibernate.test.mapcompelem.MapCompositeElementTest#testQueryMapCompositeElement

    This is similar design question to other "PU-scoped" metadata. Essentially, imports is a big Map across the entire Metadata/SessionFactory. So annotation-wise, there is nothing to mock. The way Strong initially handle this kind of information was to create psuedo-annotations and bind those up in the mocker. Not at all a fan of that. IMO the mocker ought to create a OO view of the "PU-scoped" metadata (<persistence-unit-metadata/> + select settings) in addition to augmenting the annotations.

  • no support for JaxbInheritanceType.UNION_SUBCLASS org.hibernate.test.unionsubclass.UnionSubclassTest org.hibernate.test.unionsubclass.alias.SellCarTest org.hibernate.test.unionsubclass2.UnionSubclassTest

    Yep, we'll need to add that (somehow)

  • unsaved-value on id (included in the schema) and version (not currently on the schema) -- not sure what that gets mapped to on annotations org.hibernate.metamodel.spi.binding.UnsavedValueHbmTests#testAssignedSimpleIdNonDefaultUnsavedValue org.hibernate.metamodel.spi.binding.UnsavedValueHbmTests#testIncrementSimpleIdNonDefaultUnsavedValue org.hibernate.metamodel.spi.binding.UnsavedValueHbmTests#testNonDefaultUnsavedVersion org.hibernate.metamodel.spi.binding.UnsavedValueHbmTests#testNonDefaultUnsavedTimestamp

  • There appears to be intermittent failures that seem to imply an issue with binding ordering. Commented out the tests for now, since it's intermittent. org.hibernate.test.ops.MergeTest

  • UNINVESTIGATED org.hibernate.jpa.test.jee.OrmVersionTest org.hibernate.jpa.test.ops.GetLoadTest org.hibernate.jpa.test.ops.MergeTest org.hibernate.jpa.test.ops.PersistTest org.hibernate.jpa.test.packaging.PackagedEntityManagerTest#testExplodedPar() org.hibernate.jpa.test.packaging.PackagedEntityManagerTest#testListenersDefaultPar() org.hibernate.jpa.test.xml.XmlAttributeOverrideTest#testDefaultEventListener() org.hibernate.jpa.test.xml.sequences.XmlTest org.hibernate.test.annotations.xml.ejb3.NonExistentOrmVersionTest org.hibernate.test.cache.infinispan.functional.BasicTransactionalTestCase#testQueryCacheInvalidation() org.hibernate.test.hql.BulkManipulationTest org.hibernate.test.mappingexception.MappingExceptionTest#testNotFound() org.hibernate.test.ondelete.OnDeleteTest org.hibernate.test.typeparameters.TypeParameterTest#testSave org.hibernate.test.version.VersionTest#testCollectionVersion() org.hibernate.test.component.basic.ComponentTest#testComponentQueries() org.hibernate.test.legacy.SQLFunctionsTest org.hibernate.test.onetomany.OneToManyTest org.hibernate.test.join.JoinTest

Clone this wiki locally