Re: [hibernate-dev] Where is annotation <-> column name mapped?
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 specific code wrt discriminator column On 7 déc. 2011, at 01:07, Paweł Stawicki wrote: > Hello, > > I'm trying to fix some bug on Hibernate > (https://hibernate.onjira.com/browse/HHH-6580), and I need to get > following information: > 1. Which property is an entity ID? > 2. Which column name in table corresponds to this property? > > What class/object has this information? > > I spent few hours on it, but I can't tie it all together. Maybe some > documentation would help? I found that > EntityMetamodel.getIdentifierProperty can give me answer to question > 1, but I can't find answer for question 2. > > Best regards > -- > Paweł Stawicki > http://pawelstawicki.blogspot.com > http://szczecin.jug.pl > > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Where is annotation <-> column name mapped?
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 annotation <-> column name mapped? > > Hello, > > I'm trying to fix some bug on Hibernate > (https://hibernate.onjira.com/browse/HHH-6580), and I need to get > following information: > 1. Which property is an entity ID? > 2. Which column name in table corresponds to this property? > > What class/object has this information? > > I spent few hours on it, but I can't tie it all together. Maybe some > documentation would help? I found that > EntityMetamodel.getIdentifierProperty can give me answer to question > 1, but I can't find answer for question 2. > > Best regards > -- > Paweł Stawicki > http://pawelstawicki.blogspot.com > http://szczecin.jug.pl > > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Hibernate OGM split in modules, ready for new integrations!
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's up to you to know that you don't need to install a new snapshot of the older modules, or your tests will run with the previous installation, so it's only safe if you don't make any change outside of your module (which is great, but feel free to suggest changes in other areas). Anyway for the record we all use Maven 3.0.3, I don't think anybody tests the build on older Maven versions. Regarding the formatting, please do use the Hibernate Core style, when you see something formatted differently that was a mistake. Cheers, Sanne On 6 December 2011 21:45, Alex Snaps wrote: > Hey Sanne, > I started creating the layout for the hibernate-ogm-ehcache module. > Now I stumbled on something, given I'm no maven expert, I think might > not be quite right: > from the parent project, it couldn't resolve the dependency to > hibernate-ogm-core, so I first had to install that from the > ./hibernate-ogm-core module, so I could build from the root. > I think this might not be what is wanted though ... Is there a reason > for that ? Or is this some weirdness I experience because I used mvn2 > still ? > Otherwise I started the module on my fork on github and will work to > get something passing tests as soon as possible. > Thanks a lot for all these changes! > Alex > > PS: Also, I started using my Hibernate-core code style, but look like > this might use another, right ? > > On Sun, Dec 4, 2011 at 7:21 PM, Sanne Grinovero wrote: >> Hi Greg, >> we've implemented all changes in Hibernate OGM which we discussed at >> Devoxx to make it easier for you to create a new module and get >> started experimenting with an EHCache integration. >> >> Actually to proof myself correct I've already created a new module, >> and removed Infinispan from the main module relegating it in it's own >> extension; so while in the main pom and possibly in some comments and >> documentation Infinispan might still be mentioned as the "main" >> supported engine, it's not the case anymore as far as the >> implementation concerns: the tests of the core module are now using a >> "spiced" ConcurrentHashMap instead and we'll improve on the docs too >> as soon as we actually have an alternative. I hope this will let you >> get started quickly, basically you only have to look into the >> Infinispan module and think how to best implement the 6 trivial >> classes. >> >> The structure of the testsuite might need some warnings: since the >> tests verify the functionality via the user API, we actually want to >> re-run all the tests on each database. That's what Hibernate Core >> always did, via a couple of properties it switches the JDBC driver and >> connection details, just one class cares for the dialect which >> encapsulates the database specifics; but most code is well tested >> using a single database, so by default the testsuite runs H2 only, >> while Jenkins re-runs the full testsuite on all supported databases. >> In the case of Hibernate OGM, the code which we actually want to test >> is the integration with each database, so running tests on only one of >> them is not really an option. >> To re-run the same testsuite multiple times, and to keep all the >> database specific code and dependencies in different modules, we're >> hacking a bit around Maven by packaging the testsuite from the main >> module and referring to the same tests again in each module. >> >> Basically I'd suggest to have a look at how the >> hibernate-ogm-infinispan module reuses the test code from >> hibernate-ogm-core; most of the magic is triggered by the >> maven-dependency-plugin in the parent pom.xml and the >> org.hibernate.ogm.test.utils.InfinispanTestHelper in the test sources. >> >> Of course you can add additional EHCache tests as you like in the new >> hibernate-ogm-ehcache module, but I'd suggest to reuse all tests from >> hibernate-ogm-core. >> >> We can certainly polish this approach if it doesn't proof sound in >> practice, but I hope it's a good way to get started with it. It should >> provide some convergence of features across "databases"; if some >> feature can really not be implemented we can introduce flags to >> disable groups of tests in specific modules; for now there exists one >> such flag which disables JTA integration [1] : I'm using it with the >> Map implementation as I didn't implement transactional support on it. >> In theory you could introduce more such flags if you really need to >> disable some other tests, but that would be the least desirable option >> as we hope to provide a consistent behaviour across different backing >> databases as much as possible. >> >> The basic build information can be found here: >> http://docs.jboss.org/hibernate/ogm/3.0/r
Re: [hibernate-dev] Hibernate OGM split in modules, ready for new integrations!
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 -am hibernate-ogm-core --Hardy On Dec 7, 2011, at 1:47 PM, Sanne Grinovero wrote: > 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's up to > you to know that you don't need to install a new snapshot of the older > modules, or your tests will run with the previous installation, so > it's only safe if you don't make any change outside of your module > (which is great, but feel free to suggest changes in other areas). > Anyway for the record we all use Maven 3.0.3, I don't think anybody > tests the build on older Maven versions. > > Regarding the formatting, please do use the Hibernate Core style, when > you see something formatted differently that was a mistake. > > Cheers, > Sanne > > On 6 December 2011 21:45, Alex Snaps wrote: >> Hey Sanne, >> I started creating the layout for the hibernate-ogm-ehcache module. >> Now I stumbled on something, given I'm no maven expert, I think might >> not be quite right: >> from the parent project, it couldn't resolve the dependency to >> hibernate-ogm-core, so I first had to install that from the >> ./hibernate-ogm-core module, so I could build from the root. >> I think this might not be what is wanted though ... Is there a reason >> for that ? Or is this some weirdness I experience because I used mvn2 >> still ? >> Otherwise I started the module on my fork on github and will work to >> get something passing tests as soon as possible. >> Thanks a lot for all these changes! >> Alex >> >> PS: Also, I started using my Hibernate-core code style, but look like >> this might use another, right ? >> >> On Sun, Dec 4, 2011 at 7:21 PM, Sanne Grinovero wrote: >>> Hi Greg, >>> we've implemented all changes in Hibernate OGM which we discussed at >>> Devoxx to make it easier for you to create a new module and get >>> started experimenting with an EHCache integration. >>> >>> Actually to proof myself correct I've already created a new module, >>> and removed Infinispan from the main module relegating it in it's own >>> extension; so while in the main pom and possibly in some comments and >>> documentation Infinispan might still be mentioned as the "main" >>> supported engine, it's not the case anymore as far as the >>> implementation concerns: the tests of the core module are now using a >>> "spiced" ConcurrentHashMap instead and we'll improve on the docs too >>> as soon as we actually have an alternative. I hope this will let you >>> get started quickly, basically you only have to look into the >>> Infinispan module and think how to best implement the 6 trivial >>> classes. >>> >>> The structure of the testsuite might need some warnings: since the >>> tests verify the functionality via the user API, we actually want to >>> re-run all the tests on each database. That's what Hibernate Core >>> always did, via a couple of properties it switches the JDBC driver and >>> connection details, just one class cares for the dialect which >>> encapsulates the database specifics; but most code is well tested >>> using a single database, so by default the testsuite runs H2 only, >>> while Jenkins re-runs the full testsuite on all supported databases. >>> In the case of Hibernate OGM, the code which we actually want to test >>> is the integration with each database, so running tests on only one of >>> them is not really an option. >>> To re-run the same testsuite multiple times, and to keep all the >>> database specific code and dependencies in different modules, we're >>> hacking a bit around Maven by packaging the testsuite from the main >>> module and referring to the same tests again in each module. >>> >>> Basically I'd suggest to have a look at how the >>> hibernate-ogm-infinispan module reuses the test code from >>> hibernate-ogm-core; most of the magic is triggered by the >>> maven-dependency-plugin in the parent pom.xml and the >>> org.hibernate.ogm.test.utils.InfinispanTestHelper in the test sources. >>> >>> Of course you can add additional EHCache tests as you like in the new >>> hibernate-ogm-ehcache module, but I'd suggest to reuse all tests from >>> hibernate-ogm-core. >>> >>> We can certainly polish this approach if it doesn't proof sound in >>> practice, but I hope it's a good way to get started with it. It should >>> provide some convergence of features across "databases"; if some >>> feature can really not be implemented we can introduce flags to >>> disable groups of tests in specific modules; for now there exist
[hibernate-dev] Avoid need for bidirectional relations in Search
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
Re: [hibernate-dev] Avoid need for bidirectional relations in Search
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 Place instances which needs updating on a change of a given address. Sure there is way, but is it effective and worth the effort? --Hardy ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Avoid need for bidirectional relations in Search
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 entities. Sanne On 7 December 2011 14:13, Hardy Ferentschik wrote: > > 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 Place instances which needs updating on a change of a > given address. > > Sure there is way, but is it effective and worth the effort? > > --Hardy > > > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Avoid need for bidirectional relations in Search
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 we shouldn't investigate it. > and I don't see > why we should require to define relations redundantly on both > entities. Because in so many cases it just makes sense to have bidirectional associations. Often the use of uni-directional association is based on some not required "minimalistic thinking" --Hardy ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Avoid need for bidirectional relations in Search
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 many ways the bidirectional association is a pre computed query for us. If we don't have it we need to do a full text query to guess. With the ORM info, we still need to do the query but at least we know which association we are talking about (if the assoc is bidirectional). But in Hibernate, this info is not really carried on to the runtime. So in practice we don't have it. But if a contributor want to give this idea a try, we could explore it. My guess that it won't be nearly as efficient as what we have today. Emmanuel On 7 déc. 2011, at 15:03, 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 > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] mutable versus immutable natural keys
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. Basically, is "immutable" a hint from the user that the values cannot change (so that we can perform certain optimizations)? Or is "immutable" a mandate that we have to verify the natural key has not changed, either through Hibernate or "behind" us? Today we kind of have a blend of those two. Personally I think we should take it as a hint from the user that the values will not change. WDYT? -- st...@hibernate.org http://hibernate.org ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] mutable versus immutable natural keys
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 we say that a mapped natural key is > mutable or immutable. Basically, is "immutable" a hint from the user > that the values cannot change (so that we can perform certain > optimizations)? Or is "immutable" a mandate that we have to verify the > natural key has not changed, either through Hibernate or "behind" us? > > Today we kind of have a blend of those two. > > Personally I think we should take it as a hint from the user that the > values will not change. WDYT? Would the hint mechanism involve any detection of changed values at all? What would the user see if a natural key were changed? -CB ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] mutable versus immutable natural keys
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 changed? The other thing that I did not draw out as well as I could, is where the value changed. Did it change as part of the Hibernate Session? Or did the value change in the database. It is this last bit that we do today when the user says immutable, that I dont think should always be getting done. Essentially, we are always checking the database snapshot for these entities to make sure this immutable natural key value did not change. I think that specifically should be an additional "opt in" behavior. -- st...@hibernate.org http://hibernate.org ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] mutable versus immutable natural keys
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 whether this process is trying to change the value or whether the value has changed in the database. But in either case we have a violation of the immutability. So I guess it will be more clear to say that immutable forces those checks. On Wed 07 Dec 2011 09:47:22 AM CST, Steve Ebersole wrote: > 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 changed? > > The other thing that I did not draw out as well as I could, is where > the value changed. Did it change as part of the Hibernate Session? Or > did the value change in the database. It is this last bit that we do > today when the user says immutable, that I dont think should always be > getting done. Essentially, we are always checking the database > snapshot for these entities to make sure this immutable natural key > value did not change. I think that specifically should be an > additional "opt in" behavior. > > -- st...@hibernate.org http://hibernate.org ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] mutable versus immutable natural keys
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 number to a primary key,
loading that entity, and the rest of the data would be cached...
Phone numbers are interesting as they are considered immutable, but in
the U.S. we infrequently have area code splits. There's also (fairly
rare) cases where people update their phone number, say, if they move
cities. Or, a phone number may be dropped and then later reused by an
entirely different user. Maybe the user can expect some disruption in
service but the expectation is service is available minutes after
porting is done.
There's also many issues dealing with various identities such as
device ID or subscriber IDs. For example MIN versus MSISDN versus MDN.
In all cases for a carrier we would store one of these values and then
build an index with the others. The index is basically a table as
such:
class NumberMapping {
@Id
long id;
String number;
int type; // usually an enum
Subscriber sub;
}
So you would select data using two columns "String, int" (not one). It
would be nice to have NaturalKey be composite, if possible...Maybe
declared as above? Or it might make sense to simply do like you do for
composite @Id.
@NaturalId
class PhoneNumber {
@Column
String number;
@Column
int type;
}
@Immutable
class NumberMapping {
@Id
long id;
@NaturalId
PhoneNumber number;
@ManyToOne
Subscriber sub;
}
The above is sort of venturing off-topic but maybe compound keys need
to be discussed as well.
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] mutable versus immutable natural keys
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 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 number to a primary key,
> loading that entity, and the rest of the data would be cached...
>
> Phone numbers are interesting as they are considered immutable, but in
> the U.S. we infrequently have area code splits. There's also (fairly
> rare) cases where people update their phone number, say, if they move
> cities. Or, a phone number may be dropped and then later reused by an
> entirely different user. Maybe the user can expect some disruption in
> service but the expectation is service is available minutes after
> porting is done.
>
> There's also many issues dealing with various identities such as
> device ID or subscriber IDs. For example MIN versus MSISDN versus MDN.
> In all cases for a carrier we would store one of these values and then
> build an index with the others. The index is basically a table as
> such:
>
> class NumberMapping {
>@Id
>long id;
>String number;
>int type; // usually an enum
>Subscriber sub;
> }
>
> So you would select data using two columns "String, int" (not one). It
> would be nice to have NaturalKey be composite, if possible...Maybe
> declared as above? Or it might make sense to simply do like you do for
> composite @Id.
>
> @NaturalId
> class PhoneNumber {
>@Column
>String number;
>@Column
>int type;
> }
>
> @Immutable
> class NumberMapping {
>@Id
>long id;
>@NaturalId
>PhoneNumber number;
>@ManyToOne
>Subscriber sub;
> }
>
> The above is sort of venturing off-topic but maybe compound keys need
> to be discussed as well.
--
st...@hibernate.org
http://hibernate.org
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
