Mapping defaults for @OneToOne
by Gail Badner
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
10 years, 10 months
Jandex 2.0 Beta - Java 8 Type Annotations, Generics, & Offline Reflection
by 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?
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.@E O2<@F S, @G T>.@D O3.@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 -----
10 years, 10 months
org.hibernate.persister.spi.PersisterFactory and 5.0
by 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.
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
(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.
10 years, 10 months
Maintenance on ci.hibernate.org
by Sanne Grinovero
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
10 years, 10 months
Re: [hibernate-dev] Making it pluggable how GenerationType.AUTO is mapped
by Gunnar Morling
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 <steve(a)hibernate.org>:
>
>> 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 <gunnar(a)hibernate.org>
>> 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(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>
>>
>
10 years, 10 months
Making it pluggable how GenerationType.AUTO is mapped
by Gunnar Morling
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
10 years, 10 months
