Java persistence needs to be modernized and generalized

Discussions

News: Java persistence needs to be modernized and generalized

  1. The Java community is currently focused around JPA as the persistence API but I think it's missing the big picture. JPA is a combination of several facets which themselves need to be separated into separate specifications so that we can get a better programming model. JPA consists of the data model which can be viewed as the POJOs + annotations for keys and relationships. There is an API for interacting with a data source to find and query entities within that data model and there is a set of meta data for mapping that data model to a SQL database. The problem is they are all combined in a single spec. This is problematic because it couples together different facets where are useful in their own right. Lets look at the following problems faced by Java developers. The web developer Web session data is still stuck in the dark ages. Session data is kept in a flat Map of key/value pairs. It's difficult for a developer to work with a hierarchical data model for the session which is common and the API is dumb as it doesn't automatically detect changes and just persist those to the Session like JPA can do using byte code weaving or straight copy and compare approaches. Why can't a developer pick a data model expressed as a POJO object graph and then find the root of that in a session and then walk it, update it and have changes picked up automatically. If several modules share the session then why should they all need to use the same POJOs? Why can't each module map it's own POJOs to the data model for the session? The current servlet spec or even the proposed ones are sorely lacking in modernizing the specification down this path. Read the rest here
  2. Why can't a developer pick a data model expressed as a POJO object graph and then find the root of that in a session and then walk it, update it and have changes picked up automatically.
    Maybe the problem isn't the spec but the product? I know at least a products that are capable of this. Also, with the bijection features of Seam and the-spec-formerly-known-as-Web-Beans, its very easy (efficient) for the container to know exactly which pieces of the object graph need to be replicated. Finally, JPA integration with SFSBs allows you to keep managed beans between transactions so that you can have a conversation and not worry so much about book keeping. -- Bill Burke JBoss, a division of Red hat http://bill.burkecentral.com
  3. Why can't a developer pick a data model expressed as a POJO object graph and then find the root of that in a session and then walk it, update it and have changes picked up automatically.


    Maybe the problem isn't the spec but the product? I know at least a products that are capable of this.

    Also, with the bijection features of Seam and the-spec-formerly-known-as-Web-Beans, its very easy (efficient) for the container to know exactly which pieces of the object graph need to be replicated.

    Finally, JPA integration with SFSBs allows you to keep managed beans between transactions so that you can have a conversation and not worry so much about book keeping.

    --
    Bill Burke
    JBoss, a division of Red hat
    http://bill.burkecentral.com
    Ugh... "I know at least a few products capable of this."
  4. Bill Like I said in the blog, we have almost an independant component in the extreme scale runtime called the projector which basically does this. It inflates/projects objects from a set of TupleStores and creates an objectgraph which has the root. It can detect changes to that graph and later the 'projector client' can ask the ObjectGraph for the changes and 'flush' them back to the TupleStore. I had it made to be independant looking for other opportunities to reuse this kind of approach but I don't want to keep doing it in a proprietary fashion. ADO.Net now has some very cool features in this area around EMF etc and I'd like to see Java having a competitive feature set.
  5. Ugh...
    Heh. At first I thought it was someone groaning at your barely subtle plug. Then I realized it was you, regretting not making it an explicit plug.
    Finally, JPA integration with SFSBs allows you to keep managed beans between transactions so that you can have a conversation and not worry so much about book keeping.
    Is that a general JPA feature, or something JBoss/Seam-specific? Regardless, can you point to any good starter documentation around this? -joe http://www.mantis-tgi.com focus on delivery
  6. The irony ..[ Go to top ]

    Bill -
    Maybe the problem isn't the spec but the product?/blockquote> Pot, meet kettle. Peace, Cameron Purdy Oracle Coherence: Data Grid for Java, .NET and C++
  7. Seam? You're kidding right?[ Go to top ]

    Also, with the bijection features of Seam and the-spec-formerly-known-as-Web-Beans, its
    There's little that's easy with Seam... just getting it configured is a nightmare of jars and XML files. The value of Seam diminishes quickly once you leave DB persistence, but even on the topic of Hibernate and Seam, the error messages as overly cryptic and pretty much useless most of the time. You'd do well to clean up error handling and message along with adopting convention over configuration like the rest of the world is doing. Having worked on a Seam project I can firmly say I will avoid it in the future. Spring is still a far better option. Don't get me wrong though, I like you JBoss guys, but man you need to clean up the tools.
  8. Try Apache Cayene[ Go to top ]

    I tried apache cayene for a project found lots of fresh ideas like Cayenne GUI Modeler ........it can auto generate ...ORM code by specifying an existing database /schema ........native XML serialization.......web services integration.........i simply time wasted in hibernate xml files and witting boiler plate code can be spent on something more important like real development ....i will encourage users to take Cayenne for a spin ....also share if they like it
  9. Re: Try Apache Cayene[ Go to top ]

    I tried apache cayene for a project found lots of fresh ideas like Cayenne GUI Modeler ........it can auto generate ...ORM code by specifying an existing database /schema ........native XML serialization.......web services integration...
    ORM overkill.
  10. I tried apache cayene for a project found lots of fresh ideas like Cayenne GUI Modeler ........it can auto generate ...ORM code by specifying an existing database /schema ........native XML serialization.......web services integration...


    ORM overkill.
    Cayenne is far simpler and more productive in practice. But it isn't as feature rich and HB. It may be ORM overkill - but I'll take either one of the roll-your-own JDBC appraoch any day and twice on Sunday :~)
  11. correction ...[ Go to top ]

    I'll take either one over the roll-your-own
  12. I commented on the blog vs here. The short of it ... I agree.
  13. There is a difference between a specifications and products or IDEs developed to support the development. Unless you want specifications for an IDE for you. I think Seam framework, Web Beans and some others are the answers to your questions but I see it unnecessary to add new spec for your personal needs.
    There is an API for interacting with a data source to find and query entities within that data model and there is a set of meta data for mapping that data model to a SQL database.

    The problem is they are all combined in a single spec. This is problematic because it couples together different facets where are useful in their own right. Lets look at the following problems faced by Java developers.

    The web developer

    Web session data is still stuck in the dark ages. Session data is kept in a flat Map of key/value pairs. It's difficult for a developer to work with a hierarchical data model for the session which is common and the API is dumb as it doesn't automatically detect changes and just persist those to the Session like JPA can do using byte code weaving or straight copy and compare approaches.
    This looks more a design issue then specification.

  14. Web session data is still stuck in the dark ages. Session data is kept in a flat Map of key/value pairs.
    Sigh, I know that there are frameworks, products and APIs for this...but I wonder why? For 99% of all real world application programming, you are better off storing the "session" data into a database, access it in whatever way you want and turn the "session" data into "request" scoped data as it should be. Which in turn will provide surprisingly simple ways of handling things like users opening more than one browser window into the same web application and the like......and the good thing: You get the requested API for free, since whatever ORM mapping framework you'll use, it *is* the API.