Hi Pawel,
Check out the AbstractEntityPersister constructor and it's use of
PersistentClass
persistentClass.getIdentifier().getColumnIterator();
And for regular properties
persistentClass.getPropertyClosureIterator();
property.getColumnIterator();
SingleTableEntityPersister has sp
Hi Paweł,
You can get the identifier column names from
AbstractEntityPersister.getIdentifierColumnNames() .
Regards,
Gail
- Original Message -
> From: "Paweł Stawicki"
> To: hibernate-dev@lists.jboss.org
> Sent: Tuesday, December 6, 2011 4:07:20 PM
> Subject: [hibernate-dev] Where is an
Hi Alex,
I'm not sure if there is a way in Maven to have it find the other
modules automagically; if there is I'm not aware of it: I generally
expect projects to be built from the root, so what you did is the same
approach I usually take.
You can then build the module only to save some time, but it
Hi,
for what it's worth - there are so called advanced reactor build options:
http://stackoverflow.com/questions/1114026/maven-modules-building-a-single-specific-module
However, I think they are fundamentally broken. In your case you could do
something like
mvn install -pl hibernate-ogm-ehcache
This sounds as an interesting idea, I'm wonderding if it could be doable:
https://forum.hibernate.org/viewtopic.php?f=9&t=1013706
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
On Dec 7, 2011, at 3:03 PM, Sanne Grinovero wrote:
> This sounds as an interesting idea, I'm wonderding if it could be doable:
>
> https://forum.hibernate.org/viewtopic.php?f=9&t=1013706
In the Place, Address example from the docs. If the relations is not
bi-directional,
how do you find the P
I'm not sure about estimating the effort, nor if it's possible at all,
but we aren't lazy right?
It seems to me it might be a useful feature; people expect us to know
pretty well how the entities relate if that's defined, and I don't see
why we should require to define relations redundantly on both
On Dec 7, 2011, at 3:18 PM, Sanne Grinovero wrote:
> nor if it's possible at all
I guess the question is whether there is a generic way to find the entities
which contain a certain entity.
Maybe we could even do that via Lucene!?
> but we aren't lazy right?
Of course not ;-) Not saying that
Without the ORM info, we cannot guess that. Or more specifically we can guess a
superset of that. Remember that you can have two (or more) unidirectional
associations between two entity types. So we would need to reindex all Places
where the Address is referenced in any of the associations. In m
One of the enhancements I want to get into 4.1 is HHH-2879 / HHH-2896
regarding adding an actual API for entity loading by natural key.
However, I think at the same time we should be more explicit and
consistent about what it means when we say that a mapped natural key is
mutable or immutable.
On 12/07/2011 10:29 AM, Steve Ebersole wrote:
> One of the enhancements I want to get into 4.1 is HHH-2879 / HHH-2896
> regarding adding an actual API for entity loading by natural key.
Woot.
> However, I think at the same time we should be more explicit and
> consistent about what it means when
There is a 3rd option in regards to immutable... to say that it is
immutable, requiring a check.
So:
1) mutable
2) immutable (no enforcement)
3) immutable (enforced)
> Would the hint mechanism involve any detection of changed values at all?
>What would the user see if a natural key were chan
Part of the problem with saying that a natural key is immutable is when
entities are reattached. We do not know whether the application is
attempting to update the value. The only solution there is again to
read the database snapshot and compare values. Unfortunately that wont
tell us whethe
On Wed, Dec 7, 2011 at 6:08 PM, Steve Ebersole wrote:
> But in either case we have a
> violation of the immutability.
One of the use cases way back when I tried using Natural Keys was for
accessing user accounts indexed by phone number. So 90% of our data
access pattern was just mapping a phone
Simple versus compound keys does not effect this discussion of
mutable/immutable.
Composite natural keys are already supported.
On Wed 07 Dec 2011 08:42:11 PM CST, Elias Ross wrote:
> On Wed, Dec 7, 2011 at 6:08 PM, Steve Ebersole wrote:
>
>> But in either case we have a
>> violation of the
15 matches
Mail list logo
