Announcement Announcement Module
Collapse
No announcement yet.
Data persistence WITHOUT a database? Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Data persistence WITHOUT a database?

    OK. Here it comes.

    I am sick and tired of the myriad of specifications, implementations, projects and products that claim to provide 'POJO-Persistence in a RDBMS'.
    Since Hibernate 2.4 there is not a single persistence framework that would work as expected, without imposing severe limitations on the application architecture, objects, work-flows, processes etc.

    JDO IMVHO failed to provide simplicity, which doomed it.

    JPA IMVHO is a GiNormous step in the wrong direction. Mandating useless features, and making key language and OOP constructs as 'optional' and 'vendor-specific' made JPA seriously unusable, unless you are comfortable with writing single-vendor-only code.

    Most, if not all of these projects bury themselves with problems arising from the fact, that OBJECTS ARE NOT RELATIONAL.

    I have come across a couple of products, that provide PURE OBJECT PERSISTENCE. But most of them are extremely expensive and since there is no unique API using any of them is a Disaster-Waiting-To-Happen.

    Now... Please! This is not a Flame-Theme.

    I just want to ask if anyone has seen and/or used a PURE OBJECT PERSISTENCE engine/framework/project/product.

    So far I have seen DB4O, its supposedly open-source equivalent JODB and a couple of Prevalence products, but I have just skimmed the surface there: Prevayler, PBeans.

    I am very interested in YOUR experience with OODBMS-es

  • #2
    Originally posted by andy
    You're sick of specifications ? yet a specification is there to provide a standardized API so there can be multiple implementations of that API all meaning that you have the same application code. They are there for a very good reason. Specifications and expert groups are always there for your input on what you want and what matters to your app.
    I am not opposing to API, exactly the opposite. However I believe that APIs MUST be self-sufficient and complete.
    The JDO specification makes collection persistence optional (OK, JDO2 specifies collections persistence, but ...), the JPA has rudimentary collection persistence, that COMPLETELY relies on vendor extensions (WTF!!!). That makes it usable only to persist the most-basic objects: property maps. This actually degrades a supposedly OODBMS spec into a useless specification for a JDBC wrapper.

    Originally posted by andy
    JDO not providing simplicity ? Perhaps if you actually define what is not simple with makePersistent(), deletePersistent() people then could offer some help.
    Actually I am not visualizing the API, but the implementations.
    Code generation, compile-time enchelada, HUMONGOUS xmls... These things are just too much for me...
    How can I develop an application that uses only an API, when I MUST execute COMPILE-TIME bull-s**ts that depend on the actual RUNTIME!!!
    And the worst part: the need to specify Database-Specific parameters at development time...
    And I had to make use of this and still be able to make modules! Awful!
    I am not trying to convert a PHP contact form into Java. I am trying to build Enterprise applications...
    Some times I get so despaired, that I start thinking about migrating to PHP...

    I always end up developing for a SPECIFIC provider for a SPECIFIC Database, for a SPECIFIC server. So what use are APIs, if you end up bound to a specific implementation? That is why we still hang with Hibernate 3.1: no generic API, no false sense of decoupling.

    Spring is the only thing that provides a light in the tunnel, keeping me from loosing the last flickers of sanity.

    Originally posted by andy
    The JDO2 EG, Apache JDO and other groups would be very interested in your experiences and what you think is not right. If you choose to not provide such feedback then the problem becomes yours. People are there to help, and do want to. All OODBMS provide their own API, and JDO can be seen as an attempt at providing a standardized API.
    I have my doubts as to whether those APIs are salvageable. When things get are left unfixed for a long time it might be better to just start over from scratch.

    I am actually trying to find a replacement persistence that provides Object Storage without imposing non-object constraints based of its underlying storage. I want to annihilate RDBMSes from my life and work.

    Comment


    • #3
      Data persistence WITHOUT a database?

      Have a look at NeoDatis ODB. It is an Open Source (LGPL) OODB.

      http://www.neodatis.org

      Probably, one of the simplest way to persist objects.

      Comment


      • #4
        Originally posted by Lachezar View Post
        OK. Here it comes.

        I am sick and tired of the myriad of specifications, implementations, projects and products that claim to provide 'POJO-Persistence in a RDBMS'.
        Since Hibernate 2.4 there is not a single persistence framework that would work as expected, without imposing severe limitations on the application architecture, objects, work-flows, processes etc.
        And which additional limitations impose newer versions of Hibernate (3.x)?

        OBJECTS ARE NOT RELATIONAL.
        No big news. Introduction for each ORM provides this statement as thevery reason for ORM existence.

        The problem with pure OO DBMS is that they (till the moment at least) can not work as real-world DBMS despite all efforts, probably, it would change but unlikely in the near future.

        I have come across a couple of products, that provide PURE OBJECT PERSISTENCE. But most of them are extremely expensive and since there is no unique API using any of them is a Disaster-Waiting-To-Happen.
        Yes, there were a lot of attempts and AFAIK pure OODBMS have preceded ORM. Latter have appeared as answer to incapability to produce usable OODBMS.

        BTW, even pure OODBMS will not solve some incompatibilities between objects in memory and in the DB (e.g. identity problem).

        Regards,
        Oleksandr
        Last edited by al0; Jan 13th, 2008, 11:13 AM. Reason: Addition

        Comment


        • #5
          Re: Data persistence WITHOUT a database?

          Hi!

          The db4o team will soon release a version with "Transparent Persistence" (TP) which will get us closer to "data persistence WITHOUT a database".

          TP consists in two separate features working together: Transparent Activation (TA) and Transparent Update (TU).

          Transparent Activation (already present in the latest version of db4o) automatically loads only the absolute minimum objects from db as you go deeper in the object graph (you don't need to specify the object activation depth, a value which tells db4o how deep to go when loading an object graph) which results in less memory consumption and more performance.

          The other feature, Transparent Update (soon to be released) automates the storage operations. With TU you don't need to explicitly store objects, db4o automatically detects when objects are updated and enlists them for storing upon transaction commit. This leads to simpler code and, again, more performance.

          So, this is more than just "forget about annotations, XML, etc." but rather "forget about the db" =)

          Best regards,

          German
          Last edited by German; Jan 14th, 2008, 10:31 PM. Reason: Added some hyperlinks

          Comment


          • #6
            can any one tell me that i am setting updates in database tabele
            first of all i get the list of data in table like this
            List list=dao.findAll();
            it is nice and sipose i do some changes in and stor like this
            call c=(call)list.get(2);
            dao.save(c);
            it is fin but when i dispaly list it will show old data not updated dated data.
            if i get again list formn data base then it will work,but this is not good that to get same list twice to data base.is there any way to to get updated data without connecting to database

            Comment

            Working...
            X