New version of "thin & lightweight" PriDE O/R-Mapper released

Discussions

News: New version of "thin & lightweight" PriDE O/R-Mapper released

  1. PriDE is a light weight open source O/R Mapper that has been quietly developed and used since 2001. PriDE v2.1.2 comes as a single library of less than 100k, without requiring XML or any libraries beside the JDK. PriDE "takes pride" in being really lightweight and transparent compared to JDO implementations or O/R Mappers like Hibernate.

    It doesn't follow any persistence management standards but relies on common design patterns and is production-proved in both J2SE and J2EE environments.

    Additional documentation, a 15-minute tutorial and an eclipse plugin can be found on http://pride.sourceforge.net

    Threaded Messages (41)

  2. PriDE license:

    http://pride.sourceforge.net/EGPL.html
  3. It is a good design for generated code, I hope nobody writes this kind code manualy.
  4. Transparent/No XML[ Go to top ]

    Okay, from a first glance at it:

    "transparent": Having a requirement for all your persistent objects to extend a common baseclass is not what we (hibernate team) would call transparent.

    "No XML": Well, instead you have strange "RecordDescriptor" object for every persistent class, which is esentially a mapping file embedded in the code. Not that I'd say this is necessarily a bad thing (I am not one of those advocating to move as much as possible to XML files), but this seems like a strange "advantage" to me.

    This might still be a nice project for simple persistence needs, just wanted to clear up some "marketing"
  5. Bullshit[ Go to top ]

    How nice of you on the hibernate marketing team to "clear up" some "facts".
  6. Transparent/No XML[ Go to top ]

    The term "transparent" may be a little missleading here in the context of persistence management. It was meant to express that PriDE is really so small that its working principles and source code can be completely understood by a single developer without too much effort. We believe that this is a crucial characteristic for frameworks working on the bottle neck of an enterprise application.

    Concerning derivation from a base class:
    This is not required but only an option for very simple examples like in PriDE's quickstart tutorial. Of course you can separate the mapping from the actual data. But nevertheless you are right: PriDE is *not* transparent in the sense that the developer doesn't know that he is performing persistency operations. But is that really a problem in typical layered software architectures were e.g. persistence management is encapsulated in data access objects anyway?

    Concerning XML:
    Sure, there is a mapping mechanism in PriDE as well (of course, because it is essentially an O/R-Mapper). However, representing the mapping in form of accessible Java objects has the advantage of being as flexible as possible, e.g. for such awful but necessary things like twisting the table order in a join depending on the query conditions (yes indead, these things happen :-). In my opinion, XML should only be an *option* for an external, text-based static mapping representation. But not an integral must.
  7. Transparent/No XML[ Go to top ]

    Okay, I stand corrected (at least a little :)). I freely admit that I did not read far enough into the documentation to discover that.
  8. transparent[ Go to top ]

    The term "transparent" may be a little missleading here in the context of persistence management. It was meant to express that PriDE is really so small that its working principles and source code can be completely understood by a single developer without too much effort. We believe that this is a crucial characteristic for frameworks working on the bottle neck of an enterprise application.
    Heh heh heh. I used to think that too ;-)

    50 000 LOC later....
    However, representing the mapping in form of accessible Java objects has the advantage of being as flexible as possible, e.g. for such awful but necessary things like twisting the table order in a join depending on the query conditions (yes indead, these things happen :-). In my opinion, XML should only be an *option* for an external, text-based static mapping representation. But not an integral must.
    Very, very interesting. The very earliest versions of Hibernate used a similar approach (field names embedded in the source of the domain model) - I was copying a persistence layer in an olde SmallTalk application I had used. I gave up on that pretty quickly, but never, ever, really liked XML as a solution. That's why I've been so keen on embracing JSR175 annotations, it really gives me what I wanted 3 years ago and couldnt do at the time.

    Can you explain what you mean about "twisting table order"? I don't understand.
  9. twisting table order[ Go to top ]

    Can you explain what you mean about "twisting table order"? I don't understand.
    This was just a perverse example for nasty database performance problems which somehow must be addressed individually by the persistence manager. In that particular case it turned out that the order of tables in an SQL join query like "select * from t1,t2 where ..." had to be flipped depending on the query conditions. Maybe a better example are queries where complete tables can simply be omitted depending on the query conditions.
    This is is awful drudgery beyond all proper concepts of course, but it must be done somehow. And it's just nice to work with a persistence manager which allows doing these things and keeps me from falling back completely to the plain JDBC hell ;-)
  10. Object/Relational Mapping, eh? What an interesting idea. You guys are going to be rich!
  11. Let the tail-chasing commence.
  12. You guys are going to be rich!

    The love of money is the root of all evil. Be content with what you have Race Condition.
  13. Object/Relational Mapping, eh? What an interesting idea. You guys are going to be rich!
    Well, at least they do not pretend to develop a "J2EE" container that never will be certified as being compliant with the J2EE spec.

    SCNR,
    Lars
  14. GPL License for a library?[ Go to top ]

    Why GPL License for a library? The framework seems to be worth a look - mostly because of its small size and his (apparent) ease of use, but I think very few companies would allow using a virally licensed library for a real world application. Not mine, for sure.
    <br>
    I thought the game was: GPL for complete applications, LGPL for libraries.
  15. Pride and pBeans vs. the others?[ Go to top ]

    I've been looking a bit at pBeans (http://pbeans.sourceforge.net/) for a small hobby project, a cool lightweight O/R mapping layer as well, which even creates tables etc automatically (which should be a basic requirment for a tool of this kind). pBeans does not require XML descriptors either. Either tool should be considdered for larger projects, Hibernate (my first choice), JDO or Enitiy EJB's are more suited for these kind of tasks.

    Don't get me wrong here, I'm not trying to sell either pBeans or Pride. Pride seems to be a good piece of work, but IMHO a lot of open source projects today fail to solve problems that other projects released haven't solved already. I'd love to see more similar projects joining forces instead of us poor seekers having to choose between minor differences in implementation.
  16. I want options[ Go to top ]

    I hear a lot people complaining about too many projects with similar goals. I don't see why that's a problem. I would rather spend a little while trying to choose a product I like than grok a monopolistic product. There's already enough frustration with the local phone company, cable company, the PC and all. I think options are only healthy and people should experiment. Now when it comes to defining a standard I do agree that ideas should converge.
  17. I want options[ Go to top ]

    I hear a lot people complaining about too many projects with similar goals. I don't see why that's a problem. I would rather spend a little while trying to choose a product I like than grok a monopolistic product. There's already enough frustration with the local phone company, cable company, the PC and all. I think options are only healthy and people should experiment. Now when it comes to defining a standard I do agree that ideas should converge.
    100% agreed. But I like to add that if the open source projects risked a look to either side, and have a look at the technical solutions found by their "competitors", all sides may benefit from it. At the moment, everyone has the view that his and only his solution is the right one.

    Cheers,
    Lars
  18. I want options[ Go to top ]

    I would like to know what, 3 years back, they did look at - and if those options were deemed not ready for prime time - and if that caused them to roll their own. I think the trend is more that people are trying to share code that they developed over a long period of time, as opposed to an increased tendency to reinvent the wheel. I'm not saying people need to go rush out and use it, just because its been open sourced, but to make assumptions surrounding the development of this particular pice of software is plain rude. Its not like they started the project last month.

    -cb
  19. I want options[ Go to top ]

    I hear a lot people complaining about too many projects with similar goals. I don't see why that's a problem.
    I am a whiner, but I complain about slightly different thing:
     – introductory pages of many project simply state the goal and do not provide with information why other projects with the same goal do not fit;

    PrIDE is a fortunate exception: is does explain “Why another…” and I especially glad to see on the very first page what PrIDE does NOT do! Much kudos to the PrIDE developers for their honesty! I wish all developers followed the lead.
  20. I like that it's lightweight. If it doesn't need tons of any other "commons-x" it's cool. I don't like that it commits you to a speciffic hierarchy by inheriting all "entities" from MappedObject. Anyways it looks like a good job.

    I don't understand the fear for descriptors since not using them moves the mappings into the code which for light mappings is ok but for huge ones ... I prefer them outside.

    I also kinda like hibernate's relationships and I wouldn't move back to explicitely use primary keys in code for navigation unless I really have to. I also don't like in a ORM solution any database column names(like in your Relationships example) but ... as I said. What I like is that it's lightweight. If the productivity with (I'll take a look at the eclipse plugin also) it would be better or equal with Hibernate I'd choose it for a desktop app for example.

    BTW what databases are supported ?
  21. What exactly does "lightweight" mean in this context? I mean: is it lightweight with respect to the jar size, or because it can prove than common operations performed by an ORM are executed with less computational intensive operations? Or is it a memory lightness? As someone pointed out, nearly every library out there could be indicated as "lightweight" if no other criteria for comparison are given.
  22. Whats wrong with inheriting from a common base class? Providing you have the source it means you can easily add common functions to all persistant entities.

    I'm interested because we do the same in an O/R tool that we are doing, and others have commented on it without saying exactly why they dislike it.

    Being a code generator its very simple to move the common code into the generated classes- but thats anti OO, and removes some flexibility/commonality.

    Thoughts would be appreciated.

    Jonathan
    Emeraldjb coming soon....
  23. Essential words[ Go to top ]

    Several words in the description I think should have been put in the description:
    1. Common class for inheritance - means that you are not allowed to follow your own hierarchies neither store complex classes from outside of your program e.g. JAXB generated class (it's actually possible, but _very_ complicated).
    2. "Reflection" - :) should I explain? No magic like byte-code manipulation, but really slow.
    But never the less this yet another ORM framework have is't own place because of simplicity, I think.
  24. reflection[ Go to top ]

    2. "Reflection" - :) should I explain? No magic like byte-code manipulation, but really slow.But never the less this yet another ORM framework have is't own place because of simplicity, I think.
    Oh please, that is simply absurd. What JDK are you using? Like ... 1.7???

    Reflection is just *not* slow in modern JVMs. Especially not compared to other costs like ... oh ... lets see ... accessing the bloody database??!!
  25. I don't like that it commits you to a speciffic hierarchy by inheriting all "entities" from MappedObject.
    You don't need to inherit your entities from MappedObject. It is just an option for very simple environments and therefore used in the PriDE Quickstart chapter. For more serious applications you can of course separate your entities from the database adapter. (See PriDE Design Patterns: Separation of database and business concerns).
  26. Well, PriDE doesn't make too much assumptions on the capabilities of the underlaying database system, just as any other O/R mapper based on JDBC. Databases currently known to work with PriDE are Oracle 9, DB2, MySQL, Postgres, Pointbase, Cloudscape and MS SQLServer. The PriDE kernel doesn't even required prepared statements allowing to use even very limited databases resp. database drivers like MS SQLServer 6.5.

    Concerning relationships:
    This is actually an issue of many, many discussions. We believe (and experienced) that this feature can become very dangerous in complex systems due to unforeseable side effects which are very difficult to analyse and fix. In simple systems it is nice of course, but - due to simplicity - not essential on the other hand. Additionally, in a layered software architecture, relationships should usually only be of interest in the very lowest integration layer and are therefore of limited use. This is one of the reasons, why e.g. relationship support will probably vanish from the EJB standard in the 3.0 specification.
  27. This is one of the reasons, why e.g. relationship support will probably vanish from the EJB standard in the 3.0 specification.
    Relationships are alive and well in EJB3.
  28. useless relationships[ Go to top ]

    We believe (and experienced) that this feature can become very dangerous in complex systems due to unforeseable side effects which are very difficult to analyse and fix. In simple systems it is nice of course, but - due to simplicity - not essential on the other hand. Additionally, in a layered software architecture, relationships should usually only be of interest in the very lowest integration layer and are therefore of limited use.
    whoa, thats a mouthful. You fail to explain what "unforeseable side effects" you have in mind. In addition, the fact that a feature is only used (by you) on a certain application layer does not say anything with regard to its usefulness, IMO.
    This is one of the reasons, why e.g. relationship support will probably vanish from the EJB standard in the 3.0 specification.
    now, that is news to me. Where did you hear that relationships were to be dropped from EJB? My information is that the next spec might be modeled after Hibernate, which points to the opposite..

    regards
  29. useless relationships[ Go to top ]

    This is one of the reasons, why e.g. relationship support will probably vanish from the EJB standard in the 3.0 specification.
    now, that is news to me. Where did you hear that relationships were to be dropped from EJB? My information is that the next spec might be modeled after Hibernate, which points to the opposite..regards
    To clear up the confusion: container-managed relationships are indeed removed (since the classes are no longer abstract) but relationships are definitely still in.

    It just means a couple of extra lines of code to maintain referential integrity...

    --
    Cedric
  30. Ok, I agree, my statement about relationships was too indistinct. It is the *container-managed* relationships which were removed, leading to a very important shift of responsibility: maintaining a relationship becomes an integral aspect of the *application* rather than the *container*, avoiding one of the most significant problems with uncontrolled data load and update (one of the side effects I mentioned before). Reducing the relationship concept in that way leads exactly to the approach you can find in PriDE, with the difference that PriDE doesn't perform any entity management at all but follows a pure value object philosophy. It also takes only a very few lines of code to maintain a relationship in PriDE, just like in probably any other mentionable lightweight O/R mapper. So, in my opinion, the recent evolution of the EJB standard confirms lightweight relationship approaches. In comparison to EJB 3.0, PriDE just has the advantage to work in both managed and unmanaged environments.
  31. In my experience, container-managed relationships are not responsible in any way for "uncontrolled data load and update". How you implement referenctial integrity control in your application is the question, which, worst case, gives you a constraint violation. It's a question of testability of your entities, outside of a container. The only ORM solution (I currently remember) that uses managed relationships is EJB 2.1 entity beans. Not doing it is not a special feature.
  32. associations[ Go to top ]

    I would just comment that I regard support for associations as an absolutely basic feature of ORM. Why?

    Because the biggest performance problem you will encounter in applications with OO domain models that are persistent to relational database tables (whether you have handcoded persistence or some persistence framework) is the n+1 selects problem.

    Solving this problem by hand is, IMO, essentially impossible, at least very difficult and time-consuming. You need an ORM implementation that will allow efficient fetching of associations using outer joins. This means that the ORM *has* to know about the associations.

    In the book (shameless plug), we define the O/R mismatch in terms of the following "problems":

    (1) The problem of granularity
    (2) The problem of subtypes
    (3) The problem of identity
    (4) Problems relating to associations
    (5) The problem of graph navigation

    Two of the four problems are all about associations, and if a persistence solution does not solve these aspects of the mismatch, I would not really call it an "O/R mapper". Which is not to say it is necessarily a *bad* persistence solution. Rather, it occupies that middle-ground between handcoded persistence and full ORM, with other solutions like iBATIS. These kind of solutions make good sense for some applications.
  33. Are associations a must or not?[ Go to top ]

    Wether an O/R mapper must support relationships or not is a matter of philosophy, I think (what ever we may define as 'managed'). It is obvious, that SQL joins *must* be supported somehow by a persistence manager to ensure reasonable performance for accessing complex SQL data models. A sophisticated mapping of objects and object references to SQL tables and SQL relationships is a solution of course. However, in my opinion, it is not the only one: PriDE follows a different approach interpreting a join as a collection of objects just as the result of any other query too. As a consequence, the persistence layer of the application must be fully aware of the concept of SQL joins and the developer must work with it explicitly.
    But is that actually a problem? I share the opinion of Scott Ambler in his famous white paper "The Design of a Robust Persistence Layer For Relational Databases" (see http://www.ambysoft.com/persistenceLayer.pdf) where he states that you can't expect to access a relational database fully transparently without knowing SQL. So if the developer is familiar with SQL, he should be able to use joins savely. Especially he should not be limited to *outer* joins being addressed by OO reference paradigms, but should also have inner joins, subselects, and any other conditional expressions at hand required to garuantee a suitable database access signature of the application.
    In sum this is probably a less conceptual approach but a more flexible one from the SQL point of view without loosing too much of the convenience expected by an O/R mapper. It's definitely a different approach of what is propagated in most other persistence management frameworks, but it turned out to be valid in various projects. And that's why we believed it is worth to mention. It is really an alternative philosophy, providing what Harish was asking for: I want options ;-)
  34. Managed Relationships[ Go to top ]

    The only ORM solution (I currently remember) that uses managed relationships is EJB 2.1 entity beans.
    doesnt Cayenne do managed relationships? What about TopLink?

    BTW, does anybody know of a framework that allows identifying relationships (i.e. a persistent relationship that form [part of] the key of a persistent entity)? All the frameworks I have looked at so far limit the keys to simple (value-) types.

    Christian
  35. Managed Relationships[ Go to top ]

    The only ORM solution (I currently remember) that uses managed relationships is EJB 2.1 entity beans.
    Managed relationships are specified in both standards EJB and JDO and consequently can be found in all O/R mappers following these standards or claim to be functionally equivalent: OJB, TopLink, CocoBase, intelliBO, Hibernate...
  36. Managed Relationships[ Go to top ]

    Managed relationships are specified in both standards EJB and JDO and consequently can be found in all O/R mappers following these standards or claim to be functionally equivalent: OJB, TopLink, CocoBase, intelliBO, Hibernate...
    that is simply untrue with regard to JDO. Please read the specs. The new JDO 2.0 draft mentions managed relationships in 25.7 shortly under "Items deferred to next release". I know of only one JDO implementation that offers them as a proprietary extension. AFAIK Hibernate does not have them, either.

    Christian
  37. Managed Relationships[ Go to top ]

    Managed relationships are specified in both standards EJB and JDO and consequently can be found in all O/R mappers following these standards or claim to be functionally equivalent: OJB, TopLink, CocoBase, intelliBO, Hibernate...
    I guess we define "managed relationship" differently, because I'd say that Hibernate (and most of the others you listed) don't manage any relationships. Oh, they _map_ relationships to the database and manage the persistence aspect. But they don't manage object relationships in some runtime container.

    http://blog.hibernate.org/cgi-bin/blosxom.cgi/2004/06/24#comparingpersistence
  38. Managed Relationships[ Go to top ]

    BTW, does anybody know of a framework that allows identifying relationships (i.e. a persistent relationship that form [part of] the key of a persistent entity)? All the frameworks I have looked at so far limit the keys to simple (value-) types.Christian
    Ahem, I don't understand fully but you can take a look at jaxor 3.5:

    Foreign Field Mapping Metadata Available at Runtime

    This release adds the ability to use foreign field metadata at runtime. This allows developers to work with objects at the interface and metadata levels. For example, this example is the implementation of cascading deletes for entities.

    ...
  39. Managed Relationships[ Go to top ]

    The only ORM solution (I currently remember) that uses managed relationships is EJB 2.1 entity beans.
    doesnt Cayenne do managed relationships?
    I don't know what Christian Bauer and others mean by "managed" and how is this different from "mapped" or "supported" relationships? It all seems the same to me. "Relationships management/support/mapping" in Cayenne covers lots of things.

    Say when you call "painting.getArtist()" you receieve an object instance, but DB call to resolve an actual Artist is deferred till you start accessing the fields of a the Artist object. Same goes for to-many relationships.

    Or you can do "artist.addToPaintings(painting)" - this will generate the right FK on commit.

    Or you can "flatten" a join table in many-to-many, excluding it from object mode, so that the records in a join table are inserted/deleted whenever the relationship is modified.

    Also Cayenne uses relationships defined in the mapping to infer the correct order of insert/update/delete to satisfy the DB constraints during complex commits (which is kind of neat).

    Is this "management"? Cayenne is not unique in this respect (except for maybe sorting operations on commit?). I am sure other ORMs do something similar.
    BTW, does anybody know of a framework that allows identifying relationships (i.e. a persistent relationship that form [part of] the key of a persistent entity)? All the frameworks I have looked at so far limit the keys to simple (value-) types.
    Relationships in Cayenne can be based on simple or compound keys. Cayenne can totally hide this fact, and you don't (and probably shouldn't) even need to have FK or PK as object properties! Is this what you were referring to?

    Andrus
  40. useless relationships[ Go to top ]

    whoa, thats a mouthful. You fail to explain what "unforeseable side effects" you have in mind. In addition, the fact that a feature is only used (by you) on a certain application layer does not say anything with regard to its usefulness, IMO.
    Well, I tried to express everything very carefully with "can", "may be", and "should", knowing that no personal experience can be generalized for the whole world. But I think, this is a useful discussion so let me add some more information:

    The side effects I observed with transparent persistent relationships are e.g.
      - Unnecessary data load. In extreme cases fetching one tiny record causes half of the system's master data to be loaded in cash
      - Undermining of self-managed concurrency control like optimistic locking. The EJB standard e.g. doesn't define anything here, so there is a strong need of self-managed mechanisms. I hope this statement doesn't start the next sub discussion ;-)
      - Undesirable data locking. As it is not specified when depended records are actually loaded, they may be blocked for other applications / threads though not actually being accessed.
      - Undesirable dissociation. Especially bidirectional relationships may cause the updates on records the developer didn't really have in mind.

    All these effects are very difficult to analyse because they are not caused by self-written und debuggable code. Problems must be proved indirectly and solved by changing the mapping configuration. However, from the configuration data it is very hard to see if a manipulation doesn't cause side effects in other parts of the application. I really made the experience that the best way to stabilize a miss-behaving persistence management with self-will is to simply remove all the tricky transparent container-managed stuff and make it really simple.
    It's a bit like the space ship of this hardrock band Desaster Area in "The Hitchhiker's Guide to the Galaxy": it stopped bucking when everyone stopped pushing all the unknown buttons ;-)
  41. useless relationships[ Go to top ]

    whoa, thats a mouthful. You fail to explain what "unforeseable side effects" you have in mind. In addition, the fact that a feature is only used (by you) on a certain application layer does not say anything with regard to its usefulness, IMO.
    Rating the usefulness of features is of course very difficult. However I think there is at least an indicator converning relationship support: A wide-spread design pattern for a layered Java-based enterprise system is the encapsulation of database interaction in data access objects (DAOs). DAOs provide all data to the upper layers in form of value objects which contain either no persistence-management information at all or an application-specific one. I.e. the application must already be designed for solving data synchronization problems by its own in higher layers. Especially remote clients must have appropriate mechanisms on board to minimize not only database access but any server interaction in general. If these mechanisms have been established once for an application they should as well be suitable in a data access layer. Therefore many features of the underlying persistence manager should already be implemented individually, limiting the usefulness of what the persistence manager has to offer.
  42. Relationships[ Go to top ]

    We believe (and experienced) that this feature can become very dangerous in complex systems due to unforeseable side effects which are very difficult to analyse and fix. In simple systems it is nice of course, but - due to simplicity - not essential on the other hand. Additionally, in a layered software architecture, relationships should usually only be of interest in the very lowest integration layer and are therefore of limited use. This is one of the reasons, why e.g. relationship support will probably vanish from the EJB standard in the 3.0 specification.
    To me relationships support is one of the main reason to use ORM in the first place! Relationships add complexity to the underlying framework, that's true, but at the same time they make the framework orders of magnitude more usable.

    Andrus