Discussions

News: Article: Defining Your Object Model with JPA

  1. Article: Defining Your Object Model with JPA (33 messages)

    In "Defining Your Object Model with JPA," Chris Maki walks through a blog's object model with JPA, using mapped superclasses and entity listeners to provide functionality that you might not have thought of. He starts off with some simple requirements of the object model, and then fulfills them – including some requirements that a DBA might offer, such as column names. The article presents only one possibility of the model, of course, and the model ignores some fairly common capabilities that one might expect in a full-featured model, but it also does a good job of expressing requirements and walking through their implementation with lots of detail.

    Threaded Messages (33)

  2. The magic of annotations[ Go to top ]

    How to turn a simple tutorial into a totally unreadable mess (to me). Guido
  3. Annotations Rule[ Go to top ]

    The magic of annotations is how to turn a simple tutorial into a totally unreadable mess (to me).
    Guido
    Hm... I do agree that the code presented in the blog could be formatted better with more spacing and have some syntax coloring. However, I disagree with the unreadable mess part. Would you prefer a pile of unreadable XML instead? I personally love JPA and think that it is the best persistence API on the market today. I find it very elegant to be able to specify my model and entity relations directly in code with annotations. I like to be able to make both, model and mapping re-factorings directly in Java class without having to additionally dig in DB and XML. This is especially useful if your business requirements allow you to generate your DB model based on your Object model, which is a huge time saver. Best, Dmitriy Setrakyan GridGain - Grid Computing Made Simple
  4. Re: Annotations Rule[ Go to top ]

    However, I disagree with the unreadable mess part. Would you prefer a pile of unreadable XML instead?
    Where you put your specification is up to you, but Guido said "in his opinion". I personally like annotations for basic persistence information, but would never put schema mapping as annotations in any class, since it changes at deployment and I don't want to recompile for such things. Separating concerns allows DBAs to participate in the ORM process, whereas if you just dump everything in your class then you impose everything. Again its a personal choice and based on the application.
    I personally love JPA and think that it is the best persistence API on the market today.
    Why don't you tell us exactly why you think that ? Is it that you haven't tried the alternatives and that upon encountering JPA you simply like it? No problem with that, if so. Is it the J2EE integration you like ? Clearly to make a sweeping statement you will have people disagreeing with you on such basic issues as the fact that JPA (1) can't :- 1. model indexed lists 2. model maps stored in join tables 3. model 1-N unidir FK relations 4. model compound identifiying relations 5. model Collection 6. allow datastore transactions 7. model surrogate version columns 8. model surrogate identity columns (datastore identity) 9. specify indexes in the schema ... and many more things. All of these and much more are available in other standardised persistence APIs, so yes JPA has some positive things, but it is far from the "best persistence API on the market today" :-)
  5. Re: Annotations Rule[ Go to top ]

    I personally like annotations for basic persistence information, but would never put schema mapping as annotations in any class, since it changes at deployment and I don't want to recompile for such things.
    Hm... your DB schema changes at deployment? Nice way to go :) I think many would find this approach rather mysterious. Or do you mean that the actual schema URI changes?
    Why don't you tell us exactly why you think that ? Is it that you haven't tried the alternatives and that upon encountering JPA you simply like it? No problem with that, if so. Is it the J2EE integration you like ?
    Well, I haven't tried every persistence API out there, but I have extensively worked with IBatis and less extensively with Hibernate. When I tried JPA for the fist time (about 1.5 years ago) I immediately found the annotation approach very elegant. The way it blends into JEE is a plus (not sure what you mean by not supporting transactions and some other points you made). It's definitely not a silver bullet, but I find it very natural and intuitive to use and maintain. Best, Dmitriy Setrakyan GridGain - Grid Computing Made Simple
  6. Re: Annotations Rule[ Go to top ]

    Hm... your DB schema changes at deployment? Nice way to go :)
    So you've never worked where you have a dev DB for development, and then the app is deployed on a prod server and the datastore can have slightly different structure? Ok. In your world you'd have to go off and recompile your app for the new server ...
    When I tried JPA for the fist time (about 1.5 years ago) I immediately found the annotation approach very elegant. The way it blends into JEE is a plus (not sure what you mean by not supporting transactions and some other points you made).
    Well you mention iBatis etc but, as good as they are, they are not standards-based APIs. JDO is other standards based API in Java persistence. I'd highly recommend looking it up since it provides all that you say you want (annotations, simply API, etc etc), as well as all of the other things I mentioned. Here's a starting point for your research ;-) -- Andy Java Persistent Objects
  7. Re: Annotations Rule[ Go to top ]

    So you've never worked where you have a dev DB for development, and then the app is deployed on a prod server and the datastore can have slightly different structure? Ok. In your world you'd have to go off and recompile your app for the new server ...
    Well, you don't have to be a genius to see that such cases must be avoided. I sure am staying away from recompilation of production code though :)
    Well you mention iBatis etc but, as good as they are, they are not standards-based APIs. JDO is other standards based API in Java persistence.
    I don't care about standards here as long as the product does the job (I definitely do see where your bias is coming from, not that there is anything wrong with that). I first looked at JDO perhaps 5 years ago, long before it even became a standard and liked it at first. It didn't have annotations then (there were not any), so I assume the spec had evolved. I am still not sure why JCP had standardized on 2 persistence API's, but well... Today, with reinvented POJO-EJB's, I am taking the EJB/JEE route though. Best, Dmitriy Setrakyan GridGain - Grid Computing Made Simple
  8. Re: Annotations Rule[ Go to top ]

    So you've never worked where you have a dev DB for development, and then the app is deployed on a prod server and the datastore can have slightly different structure? Ok. In your world you'd have to go off and recompile your app for the new server ...

    Well, you don't have to be a genius to see that such cases must be avoided. I sure am staying away from recompilation of production code though :)

    Well, what if the same product is to be deployed to different customers, with different table name conventions, with different database products, with different database versions, with different brothers, sisters and whatever ? Maybe better avoid having more that one customer at time ;-) Anyway, code formatting was horrible, I agree :-), but the what I am arguing is the extensive use of annotation. The funny thing is that everybody say that annotations should never be used for configuration purposes. Is it the table name a configuration parameter ? Mutatis mutandis, is it the web service endpoint a configuration parameter ? Yes ? And why there are a plenty of such (bad ?) example almost from anyone ? Guido
  9. Re: Annotations Rule[ Go to top ]

    Hm... your DB schema changes at deployment? Nice way to go :)

    So you've never worked where you have a dev DB for development, and then the app is deployed on a prod server and the datastore can have slightly different structure? Ok. In your world you'd have to go off and recompile your app for the new server ...
    I typically use one or two different database technologies for development, e.g. MySQL and HSQLDB for unit tests and then deploy to Oracle. There can be differences between my environment and production but every field I have mapped to a table exists in production. The other environments may have more columns and different indexes, etc. but fundamentally all environments should have the same common table and column names (and column types). If this isn't the case, can you elaborate on how dev and prod could be so different? As an aside, if things were to change dramatically between environments you could use a JPA orm.xml mapping file. These are a lot like Hibernate's hbm.xml files. A JPA orm.xml files can augment or completely override your Entities annotations. This provides some flexibility for you model to be used in different databases.
  10. Re: Annotations Rule[ Go to top ]

    but fundamentally all environments should have the same common table and column names (and column types). If this isn't the case, can you elaborate on how dev and prod could be so different?
    Well shall we start with case sensitivity ? There are 8 combinations of lower/upper/mixed case with/without quotes. Your ORM can do its best to allow here, but there are situations where you have to provide different settings. You could have your dev DB on MySQL, and prod on Oracle for example. You have column and table name lengths that are restrictive on some RDBMS and not on others, and similarly index/key lengths. All should have the same column types eh ? What about RDBMS that don't support some basic types ? I'm talking JDBC types here (we won't get into when the SQL types differ ... ). All JDBC drivers don't support all JDBC types so what your dev box running MySQL allows, is not necessarily what your prod box running Oracle allows. But then you could have a dev server that is open to be tailored to however the devs want it to cater for new functionality too, yet the prod server has to stay as it is (and is controlled by the DBAs anyway). You may be using some particular sequence on the dev box yet since the prod box has a different RDBMS and you can't have that, so you maybe have to change the generation strategy ... Yes, in JPA orm.xml is the answer to that issue, or better said, use of annotations+orm.xml is the answer ... but then thats what I said in my first post :-)
  11. Testing?[ Go to top ]

    So in other words you don't test what your are going to run in production?
  12. Re: Testing?[ Go to top ]

    So in other words you don't test what your are going to run in production?
    Huh? I explained why different deployments lead to different schemas. That has no bearing on what is tested obviously. Look at it another way, you have 1 version of a class, and 2 (or more) deployment architectures. Consequently, to avoid frigging about with your classes every time you want to change deployment, you would have MyClass.java (inc annotations for basic persistence if reqd) orm.xml (for MySQL) orm.xml (for Oracle) orm.xml (for Postgresql) and you simply swap the deployment file (orm.xml) for each deployment architecture. On the other hand the annotated-developer would spend his/her time swapping their beloved schema annotations :-) But then, of course, its a personal choice based on your application and architecture ... as I also said in my first post :-)
  13. Re: Testing?[ Go to top ]

    Or don't use things in test you can't use in production.. That's what I do.. So I never have to worry about "frigging" with my classes. If you use a data type in test that does not exist in production how can you know your software will handle the difference when it gets to production?
  14. Re: Testing?[ Go to top ]

    I explained why different deployments lead to different schemas. That has no bearing on what is tested obviously. Look at it another way, you have 1 version of a class, and 2 (or more) deployment architectures.
    Andy, If you have different schema in development and production, then the only time when you will test production schema is in production. In any case, the whole idea of having different schemas in development and production seems wacky to me. SQL is such a delicate dialect that differs across every DB implementation, that I would never take such a risk. If I deploy on Oracle, I will develop on Oracle; if I deploy on MySql, I will develop on MySql. Best, Dmitriy Setrakyan GridGain - Grid Computing Made Simple
  15. Re: Testing?[ Go to top ]

    Dimitriy, Has that anything to do with the article or to the basic point about use of XML/annotations ? No, but anyway you clearly don't have user-acceptance testing (UAT) so I'll explain it just for you ;-) Dev = developers need fast turn around, be able to try things etc. Typical datastores wouldn't used here consume much in terms of resources. Maybe the develop writes it on their laptop while not in the office hence no network and you wouldn't bring up a bloated pig like Oracle 10g on a laptop :-) I'd personally use HSQLDB, or MySQL ... something lightweight. UAT = same as prod but under developers control Prod = the target environment, defined by the customer and DBAs UAT and Prod would share the same orm.xml config. Dev would typically not. I repeat, this is a demonstration of why you would use split annotations and XML, putting your schema info in XML. The same argument applies when you develop software that the customer can deploy on multiple architectures, so you provide an XML mapping file with it for the datastore of the customer. But then you clearly don't do that so I repeat yet again, just for you "Again its a personal choice and based on the application". If you don't want to listen to reasons then fine ... I'm not fussed :-)
  16. Re: Testing?[ Go to top ]

    Either way you still have untested code checked in (assuming source control isn't too much bloat). I understand the need to use a different DB technology in different environments. But why would you on purpose use a data type that is not compatible with your "chosen" DB technology? I just don't understand that. So I don't understand why that's a flaw on annotations. And my personal preference would be not to allow code into UAT until it was proven to run with that schema. But that's my personal preference...
  17. Re: Testing?[ Go to top ]

    Has that anything to do with the article or to the basic point about use of XML/annotations ? No, but anyway you clearly don't have user-acceptance testing (UAT) so I'll explain it just for you ;-)
    You must be the only person here who has a clue ;-)
    UAT and Prod would share the same orm.xml config. Dev would typically not. I repeat, this is a demonstration of why you would use split annotations and XML, putting your schema info in XML.
    Well, this is what I call scratching your left ear with your right arm. Of course you can create any kind of development or deployment scheme, but the art of good architecture is KISS (KEEP IT SIMPLE STUPID!) Best, Dmitriy Setrakyan GridGain - Grid Computing Made Simple
  18. Re: Testing?[ Go to top ]

    In any case, the whole idea of having different schemas in development and production seems wacky to me.
    The only difference is table/column's name mapping and column type mappings. Thats all, you can map your String field to CLOB or LONGVARCHAR depending on your RDBMS but to your java code the mapping still the same.
    SQL is such a delicate dialect that differs across every DB implementation, that I would never take such a risk.
    That is why xxxQL (JDOQL etc.) exists, they adopts xxxQL query to concrete RDBMS by translating the query to that RDBMS's sql dialect.
    If I deploy on Oracle, I will develop on Oracle; if I deploy on MySql, I will develop on MySql.
    And if you deploy both to Oracle and MySQL (suppose you have more than one target environments/customers)? Will you develop two different projects? Why use ORM then? Why just don't use the DAO pattern?
  19. Re: Testing?[ Go to top ]

    And if you deploy both to Oracle and MySQL (suppose you have more than one target environments/customers)? Will you develop two different projects? Why use ORM then? Why just don't use the DAO pattern?
    If you deploy on both environments (very edge case requirement, but not impossible) then you have to make the best effort to ensure that your schema definitions don't differ. But then again, I will still test in both environments before even coming anywhere near the production environment. I don't understand why is it so impossible to have identical schema definitions for different deployments with JPA? Just specify different database dialects at deployment time and that's it. Best, Dmitriy Setrakyan GridGain - Grid Computing Made Simple
  20. Etherogeneous customers[ Go to top ]

    And if you deploy both to Oracle and MySQL (suppose you have more than one target environments/customers)? Will you develop two different projects? Why use ORM then? Why just don't use the DAO pattern?

    If you deploy on both environments (very edge case requirement, but not impossible) then you have to make the best effort to ensure that your schema definitions don't differ. But then again, I will still test in both environments before even coming anywhere near the production environment.

    I don't understand why is it so impossible to have identical schema definitions for different deployments with JPA? Just specify different database dialects at deployment time and that's it.

    Best,
    Dmitriy Setrakyan
    GridGain - Grid Computing Made Simple
    Never got customers with different naming conventions ? Never deployed in an already existing database where some table names were already used ? Need more ? What kind of constraints you require to you customers ? I am quite sure that your are happy to be allowed to specify webservice endpoint as annotation. Just enforce your customer to have certain url and that's it. It is so KISS that KI is not important, SS it's enough. Guido
  21. Re: Etherogeneous customers[ Go to top ]

    Never got customers with different naming conventions ? Never deployed in an already existing database where some table names were already used ? Need more ?
    You are talking about some very specific edge cases. Usually companies write their own code around their own data model, so they control all the names themselves, and, hence, are able to name stuff correctly.
    What kind of constraints you require to you customers ? I am quite sure that your are happy to be allowed to specify webservice endpoint as annotation. Just enforce your customer to have certain url and that's it. It is so KISS that KI is not important, SS it's enough.
    You have to clearly distinguish between meta-information and configuration. Column name in database can easily be viewed as meta-information as it almost never changes during deployments. URI is always a configuration property and should not be used as annotation. Best, Dmitriy Setrakyan GridGain - Grid Computing Made Simple
  22. Re: Annotations Rule[ Go to top ]

    I agree with you, Andy. We're using JDO (JPOX) in our projects and JDO looks more convenient to me. To be true I'm not actually understand the big differences between JDO and others except the former needs to enhance compiled classes. As for ORM abilities then as Andy said JPA lacks some functionality that JDO (Hibernate ?) have. Though I don't have any production experience with JPA/Hibernate but I've looked through the samples and tutorials and haven't saw any usecases that I can't implement with JDO. Any ideas why would I use other technologies like JPA/Hibernate? What benefits do I get? As for me I don't like annotations with ORM at all. Thats difficult to read and manage. Imagine all your metadata will be separated in several classes, but its easier to manage the data while its all in one place (like package.jdo metadata). And the only refactoring that I can imagine that annotations can help me in is moving entities to other packages. That's all, all other refactorings (I could think of only the Rename refactoring here) would cause DB schema changes and I should fix those changes by hands (in case if I want to migrate the data) and in this case I most likely would change the metadata - by hands also. As for the Rename refactoring its possible to have a plugin for your favourite IDE that will sync changes in java and XML metadata. Even if you don't have such a plugin, with JDO you still have the enhancement process that will validate metadata through your classes.
  23. Re: Annotations Rule[ Go to top ]

    I agree with you, Andy.

    We're using JDO (JPOX) in our projects and JDO looks more convenient to me.

    To be true I'm not actually understand the big differences between JDO and others except the former needs to enhance compiled classes.
    Try to imagine your product running on a RDBMS and, without **any** change in the source code, see it running on DB4O, on objectdb, on Versant too...... Better than nothing I would say. Ah, yes, I know that Larry Ellison doesn't like it..... Guido
  24. Re: Annotations Rule[ Go to top ]

    Is it that you haven't tried the alternatives and that upon encountering JPA you simply like it?
    Hi Andy. Why don't you "extend" JPA to the JDO level? I know your JPA version is based on the same engine as JDO, JPOX, of course these extensions wouldn't be standard but they would be very useful.
  25. Re: Annotations Rule[ Go to top ]

    Hi Andy. Why don't you "extend" JPA to the JDO level? I know your JPA version is based on the same engine as JDO, JPOX, of course these extensions wouldn't be standard but they would be very useful.
    Hola Profe, JPOX does extend JPA for some of that list (as do some other JPA impls). We have @DatastoreIdentity to have surrogate datastore columns. You can use EMF props for using datastore txns, or 1-N uni FK relations. The problem is that JPAs metadata design is shortsighted with respect to allowing vendor extensions in a clean way. In JDO there is or @Extension. In JPA there is .... nothing, nada. Vendors can add their own annotations but the absence of any hook in the XML XSD means that they can only extend in annotations, and the nature of doing that means that classes rapidly become more unreadable the more annotations you have to add to each field or class. Kinda like the XML interface was an afterthought. So basically very limiting. Besides which we're talking BASIC capabilities here, so why force vendor specifics on the innocent public ? Maybe JPA2 will be better ?
  26. I find it very elegant to be able to specify my model and entity relations directly in code with annotations. I like to be able to make both, model and mapping re-factorings directly in Java class without having to additionally dig in DB and XML. This is especially useful if your business requirements allow you to generate your DB model based on your Object model, which is a huge time saver.
    I strongly believe that what we really want is Descriptive Semantics, as commented by this W3C article: A Semantic Web Primer for Object-Oriented Software Developers.
    Describing the domain model ( Domain-Driven Design, the Book ) is a very good starting point for this approach.
    Ontologies are much more expressive than annotations or JPA/Hibernate mapping files. Try Protégé and a whole new world opens up... (takes some time to grasp & master things, though). Rob. See also: Model Driven Engineering Model Driven Architecture and Ontology Development
  27. Unformatted code[ Go to top ]

    Thanks for the comments Guido and Dmitriy. I agree that the code in the article looks terrible ;-) We are working on fixing that today. I guess in the conversion from my doc to HTML all the syntax coloring, spacing, etc. got lost.
  28. Re: Unformatted code[ Go to top ]

    The article has been updated with the formatted code, can you let me know if the code reads better? The use of annotations aside of course ;-) Thanks Chris
  29. Re: Unformatted code[ Go to top ]

    The article has been updated with the formatted code, can you let me know if the code reads better? The use of annotations aside of course ;-)

    Thanks

    Chris
    Oh yes ! A lot better. But, OK, is the whole annotation-based approach that makes me think.... Guido
  30. I've seemingly been on a never-ending search for persistence engine that meets my needs. EJB's have their well-documented problems, and Hibernate, while an impressive piece of software, is not easy to use. JPA is a step in the right direction but it's basically just "Hibernate Lite." I had always heard about JDO but never actually used it. I finally took the plunge and downloaded JPOX, an open source implementation of JDO 2. After working through some examples and becoming more familiar with it, all I can say is: Wow! This is what I've been looking for! I'm clearly no expert on Hibernate or JPA, or JDO for that matter, but after using JDO I can't for the life of me figure out why Sun and the rest of the community never embraced JDO, especially in its current 2.x version. It's FAR more functional than JPA (although, in reality, I suppose JPA does cover the most obvious use cases) and I think easier to use, too. To wit: In JDO (at least to my knowledge) one never has to override the equals() and hashcode() methods like one must do in Hibernate, if the object is used in a Collection. In addition, the whole attachment/detachment seems much more obvious and reliable to me. And, since it uses bytecode weaving instead of runtime proxies, I suspect that runtime performance is faster and memory usage is lower. There's no doubt that JDO is technically superior to JPA. It's too bad people don't give JDO a chance. I encourage you to give JDO and JPOX a try!! Ryan taconite.sf.net
  31. http://www.theserverside.com/news/reply.tss?message_id=240003
    I finally took the plunge and downloaded JPOX, an open source implementation of JDO 2. After working through some examples and becoming more familiar with it, all I can say is: Wow! This is what I've been looking for!
    Ryan - that's great. Thanks for speaking up!
    after using JDO I can't for the life of me figure out why Sun and the rest of the community never embraced JDO, especially in its current 2.x version. It's FAR more functional than JPA (although, in reality, I suppose JPA does cover the most obvious use cases)
    This is a long story to be sure, but at any rate it's great to hear your feedback. Rest assured that there remains a contingent of folks who have experience with JDO that are very clear about its functional superiority. We'd love to see more users do just what you did: actually try JDO and judge for yourself.
    and I think easier to use, too.
    Given your example, when you say ‘easier to use’, it sounds like you’re referring to the fact that JDO imposes fewer restrictions on definitions of persistent classes, which does in fact make it easier (and more powerful) to use. See http://www.jpox.org/docs/persistence_technology.html, specifically the “Restrictions on persisted classes” section. See also http://www.jpox.org/docs/1_2/jdovsjpa.html. However, comparing JPA 1.0 and JDO 2.0, it would be reasonable to conclude that in some aspects JPA is the easier API to use, e.g. XML-free configuration using annotations. Fortunately, however, the forthcoming JDO 2.1 spec handles these issues completely. In addition to specifying its own in javax.jdo.annotations it will also fully support the annotations in javax.persistence. You mentioned you're using JPOX - it is completely up to date with of 2.1 preview features. If you haven't already, take a look at 1.2-beta-4 (and make sure you grab the latest jdo2-api jar nightly build).
    In addition, the whole attachment/detachment seems much more obvious and reliable to me.
    Again, great to hear. You'll be interested to know that usage of detached objects gets even more flexible and transparent in 2.1 with the new CopyOnAttach option. This is brand new functionality that's not quite finished being specified, but you can check out the draft here: https://issues.apache.org/jira/browse/JDO-522 and take a look at the JPOX documentation for the feature here: http://www.jpox.org/docs/1_2/jdo/attach_detach.html#copy_on_attach. JPOX does have this feature implemented, but you'll need a nightly build to use it at this point.
    And, since it uses bytecode weaving instead of runtime proxies, I suspect that runtime performance is faster and memory usage is lower.
    Correct. The dirty checking mechanism in JDO is about as performant as you can get. Thanks to additional fields being weaved in at compile time, persistent instances maintain information about which fields have been dirtied in a very simple and direct way. See section 7.13 "Detachable" in the JDO 2.0 spec (specifically the jdoDetachedState BitSet). This is in sharp contrast to Hibernate/JPA's need to maintain clean snapshots of persistent instances such that they can be compared to detect changes. In the end, almost all JDO implementations (certainly JPOX) are also exposing JPA interfaces. This will help ease the way for folks if and when they see that JDO will serve them better than JPA. If an application is coded against javax.persistence, it should be simple enough to swap in a JDO implementation such as Kodo or JPOX, and then refactor the application as necessary to use JDO interfaces. Note that in JDO 2.1, interfaces are exposed that extend both javax.jdo.PersistenceManager(Factory) and javax.persistence.EntityManager(Factory) to help facilitate this kind of interoperability. See https://issues.apache.org/jira/browse/JDO-452. The JDO and JPOX dev teams are always happy to get feedback, feature requests & other questions. For issues specifically related to JPOX, check out the forums at http://www.jpox.org/servlet/forum/index and for questions about the JDO spec, consider posting to the mailing list (http://db.apache.org/jdo/mail-lists.html). We’re quite responsive :-)
  32. Chris, Your formatting looks better. Just a heads up that you forgot to update the link to your database: The database tables can be seen here. >
  33. Hi Lance Thanks for pointing that out :-) I'll see what I can do.
  34. The article has been updated, the missing diagram is back :-) Chris