Hibernate Commons Annotations: releasing a 5.0.1.Final version?
by Sanne Grinovero
Hi all,
I just sent a PR for a minor polishing patch to HCANN which seems
pretty safe and yet scores a solid benefit in terms of performance.
Considering how often we apply changes, I'd volunteer to release a
5.0.1.Final as soon as it's merged, as I assume no more changes will
flow in for a while?
There also is a long standing pull request which seems reasonable, but
I'm less familiar with that area; could someone have a look at:
- https://github.com/hibernate/hibernate-commons-annotations/pull/7
and let me know if that's safe enough to be included soonish as well?
Thanks,
Sanne
9 years, 1 month
Release: Hibernate Commons Annotations 5.0.1.Final
by Sanne Grinovero
Hi all,
Hibernate Commons Annotations 5.0.1.Final is now available in JBoss's
Nexus, and will soon be available via the Maven Central mirros.
Compared to 5.0.0.Final, only one difference:
https://hibernate.atlassian.net/browse/HCANN-74
That's a little performance improvement.
N.B. :
it's backwards compatible both at runtime and source level, but if you
compile a project using this latest version, it might fail at runtime
if you use 5.0.0.Final instead.
Thanks,
Sanne
9 years, 1 month
UserCollectionType mapping for Ceylon
by Gavin King
Hi Folks, so I'm making some first baby steps toward implementing
support for Ceylon's collections in Hibernate by trying to make use of
the existing UserCollectionType stuff.
Of course this is surely the ideal way to handle this, but bear with
me for a sec because I would like to know why what I tried didn't
work.
So I wrote my SetUserType to implement UserCollectionType, and then I
wrote the following Ceylon attribute:
oneToMany { mappedBy="city"; }
collectionType { type="hib.SetUserType"; }
shared MutableSet<Person> people = HashSet<Person>();
Which is equivalent in the following Java:
@javax.persistence.OneToMany(mappedBy = "city")
@org.hibernate.annotations.CollectionType(type = "hib.SetUserType")
@com.redhat.ceylon.compiler.java.metadata.Ignore
private final ceylon.collection.MutableSet<Person> people;
But when I ran the code, I got this error:
Caused by: org.hibernate.AnnotationException: Illegal attempt to map a
non collection as a @OneToMany, @ManyToMany or @CollectionOfElements:
hib.City.people
at org.hibernate.cfg.annotations.CollectionBinder.getCollectionBinder(CollectionBinder.java:322)
at org.hibernate.cfg.AnnotationBinder.processElementAnnotations(AnnotationBinder.java:1874)
at org.hibernate.cfg.AnnotationBinder.processIdPropertiesIfNotAlready(AnnotationBinder.java:904)
at org.hibernate.cfg.AnnotationBinder.bindClass(AnnotationBinder.java:731)
at org.hibernate.boot.model.source.internal.annotations.AnnotationMetadataSourceProcessorImpl.processEntityHierarchies(AnnotationMetadataSourceProcessorImpl.java:245)
at org.hibernate.boot.model.process.spi.MetadataBuildingProcess$1.processEntityHierarchies(MetadataBuildingProcess.java:222)
at org.hibernate.boot.model.process.spi.MetadataBuildingProcess.complete(MetadataBuildingProcess.java:265)
at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.metadata(EntityManagerFactoryBuilderImpl.java:770)
at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:797)
at org.hibernate.jpa.HibernatePersistenceProvider.createEntityManagerFactory(HibernatePersistenceProvider.java:58)
... 32 more
Is @CollectionType supposed to work with @OneToMany?
Thanks,
Gavin
9 years, 1 month
Hibernate documentation on GitHub
by Vlad Mihalcea
Hi,
What do you think if the Hibernate documentation would be on GitHub?
It would be much easier for anyone to contribute to it and maybe fix typos
and suggest improvements.
Vlad
9 years, 1 month
Fwd: Sub entities and Multi-version support
by Vlad Mihalcea
Actually both merge() and update() can still cause a "write skew"
phenomena, especially when using dynamic updates + OptimisticLockType DIRTY
<https://docs.jboss.org/hibernate/orm/4.3/javadocs/org/hibernate/annotatio...>
or OptimisticLockType ALL
<https://docs.jboss.org/hibernate/orm/4.3/javadocs/org/hibernate/annotatio...>
.
Let's say I have an imaginary Product entity with a price and a quantity,
and when I "purchase" it, I simply decrease its quantity (considering that
the price doesn't change).
1. I load the Product with price 9.99 and quantity 5 in one Hibernate
Session/HTTP request
2. Bob comes and changes the price to 14.99
3. I go back to place my order and I will use merge(). I will load the
Product with the new price but I won't be aware of that, and I'll issue a
dynamic-update on quantity, by simply decreasing.
This anomaly can currently be fixed by @Version implementation. Neither
DIRTY or ALL can detect this anomaly, because they relate to the latest
state (Bob's change) and not what I used to see in my first transaction.
That's how sub-versions would fix this because, by grouping properties
joined by a business transaction rule (price-quantity-discount), we could
eliminate conflicts between distinct groups of properties and only raise an
optimistic locking exception when a property is changed within the same
group (price-quantity-discount).
If we don't even consider something like this, we can still split the
tables into smaller ones to achieve the same goal.
Vlad
9 years, 1 month
Sub entities and Multi-version support
by Vlad Mihalcea
I've been seeing many blogs and articles against single-version optimistic
locking, which can cause a transaction to abort even if two concurrent
transactions don't modify the same records.
While dynamic updates can help, many fear to use it because of performance
issues (for very large tables).
I was wondering if we can have something like a SubEntity, which has the
Entity identifier, some properties and a version of its own. A regular
Entity could be mapped to include multiple such SubEntities, just that
those cannot overlap in properties.
Instead of having only one optimistic locking version, we could have one
version for each SubEntity. Whenever a property becomes dirty, Hibernate
will check the SubEntity it belongs to, and it will use that particular
version.
This is a realistic scenario since many business use cases don't
necessarily overlap when updating a certain Entity.
Besides the concurrency control advantage, we could offer the possibility
of fetching less data for a particular use case. Now Hibernate must fetch a
whole Entity in order to modify just some fields (we lose both on
read-performance and on write-performance this way too).
Let me know what you think of this.
Vlad
9 years, 1 month
