org.hibernate.annotations.CollectionOfElements
org.hibernate.annotations.ForceDiscriminator
org.hibernate.annotations.MapKey
org.hibernate.annotations.MapKeyManyToMany
those annotations above have been marked deprecated for a long time, time to
delete them?
---
Strong Liu
http://hiberna
+1 for moving to enum, i was looking into the issue described in hhh-6362, and
had some local fix
how about org.hibernate.engine.internal.Versioning.OptimisticLockingStrategy?
(this is what i used in my fix)
On Jun 24, 2011, at 8:43 AM, Steve Ebersole wrote:
> On 06/23/2011 05:42 PM, Gail Badn
On 06/23/2011 05:42 PM, Gail Badner wrote:
> I just ran into an issue where EntityBinding.getOptimisticLockMode() returns
> an ordinal from a org.hibernate.annotations.OptimisticLockType enum that is
> inconsistent with the static constants in
> org.hibernate.engine.internal.Versioning.
>
> Jira
Here is one of the tests I pointed you to before:
https://github.com/hibernate/hibernate-core/blob/master/hibernate-core/src/test/java/org/hibernate/metamodel/binding/SimpleValueBindingTests.java
It shows the basic steps. Pretty similar to what you had.
On 06/23/2011 02:18 PM, Max Rydahl Anderse
The NPE bug is addressed by
https://github.com/jbossas/jboss-as/commit/6fb2053524d04655413d7fbe82adf9058e3952c3
The NPE occurred because the AS7 PU service was closed pre-maturely
before the EM was.
I added logging for when we create the container managed EMF and when we
close it. That makes
I just ran into an issue where EntityBinding.getOptimisticLockMode() returns an
ordinal from a org.hibernate.annotations.OptimisticLockType enum that is
inconsistent with the static constants in
org.hibernate.engine.internal.Versioning.
Jira issue: http://opensource.atlassian.com/projects/hiber
Right. One of the design goals is to keep this startup time metamodel both
buildable by third parties and mutable by third parties. I say 'keep'
because you *can* do this today. The problem in my opinion and that of
others is simply that the old api is less then friendly.
On Jun 23, 2011 2:53 P
I think the immutability Gail was talking about only applied to classes used
internally, not anything configurable by developers. The new design should
allow for exactly what you're looking for wrt alternative deployment mechanisms.
On Jun 23, 2011, at 2:37 PM, Bill Burke wrote:
> Would be coo
Would be cool if it was metadata driven so that we could deploy Java
objects that represented a Hibernate deployment rather than relying on
configuration files. XML and annotation processors would just be used
to build the metamodel which is then handed off to the hibernate engine
for initiali
sorry i'm a bit slow here but could someone show (pseudo) code for how the new
approach would look like versus before?
Here is what I remember being used to (approximately from memory):
PersistentClass pc = new PersistentClass();
pc.setEntityName("org.model.Customer");
pc.setTable(new Table("CUS
1) is very much how I envisioned the state objects to be used (e.g., data
processed from a particular source that initializes an implementation of a
common "state" interface).
I like what you proposed for 2), however I would like to see bindings that are
immutable, at least after being built.
http://in.relation.to/Bloggers/HibernateCore400Beta2Release
--
Steve Ebersole
http://hibernate.org
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
12 matches
Mail list logo
