TOB - An ORM Replacement uses Object Models for access

Discussions

News: TOB - An ORM Replacement uses Object Models for access

  1. Ableverse has released The Object Base (TOB), which uses an object/relation/kin model as opposed to the more normal ORM model. TOB relies on a code generation step to manage relationships between and persistence of objects; this storage can be in an RDMS, although the access semantics are primarily through the object model, although SQL semantics can be used. While the relational model is the most mature and popular database theory nowadays, it lacks the simple feasibility to be combined with Object Oriented Programming methodology. People thus invented Object/Relational Mapping (ORM) technology to overcome this complexity. However, ORM should be taken as a workaround after you learned a true Object Oriented Persistent Data Model, like the Object/Relation/Kin (ORK) model behind TOB. Things will never get simplified enough until the Persistent Object Topography is expressed in native OO semantics. In order to protect end customers' existing investment on relational database systems, as well as to retain RDBMS' rich and mature management abilities, TOB stores physical data to relational databases with a clear structure via standard JDBC. RDBs are used as the so-called SwapEngine in terms of TOB. As a result, statistics, maintenance, and interoperability could be well provided by interfaces and tools of the underlying RDBMS. This is like an ORM, but differs from ORMs in some essential ways (revealed by deep look at TOB). In addition, TOB leverages code generation technology to ease development. In the Web of Web project, TOB generates 4.38MB of .java code according to 121KB of application defined Java persistent class code, to support any of the five relational databases for physical storage (the SwapEngine in TOB terms). The currently supported RDBs are: TOB persistent programming is designed to be easy and straight forward; the only thing you need to work with is your Java source code. There are no XML maps, no DDLs, no SQLs outside your Java code (SQL needs have been fairly reduced, but find persistent objects with SQL whenever needed), and SQL criteria are automatically generated as class fields at compilation, so SQL syntax is partially checked at Java compilation. And you don't even need to create the db schema by yourself, just run your java program and tables get created underground. (Oracle is an exception, because it doesn't tolerate runtime schema changes, but SQL scripts will be generated for Oracle that can be simply run before the Java application runs.) The key technology to enable TOB's runtime performance and ease of development is the Object/Relation/Kin (ORK) persistent data model, which is a derivation from the Entity/Relation model. To show the ease of persistent development based on TOB, let's see a simplified demo, consists of a binary relation (the Marriage class) and a triple relation (the Parentage class). Once you obtained an instance of the Person class, i.e.(assume you've got his/her ID as 123):Persistent p = tob.get(123); You can directly and immediately get his or her spouse and children, with just a method invocation. Just these 3 class files, compile them with the Annotation Procession Tool with the TOB jars on classpath, and run. When you create a persistent instance of Marriage:Persistent groom = ... // obtain the to-be husband Persistent bride = ... // obtain the to-be wife Persistent marriage = tob.birth(new Marriage(groom, bride));The spouse field of each newlywed will get automatically filled by TOB. And when current transaction get committed, it goes permanent. So will the children, sons and daughters collection of the new father and mother when you birth a persistent instance of Parentage. You can simply manage TOB transactions at framework level (i.e. for J2EE web apps, add a filter on /*, like the WoW Scener app does). In application code, you only need to annotate methods of persistent classes with @Reading, @Writing and @Retying accordingly. Leave the transaction handling to TOB! The sons and dauthers collections stand to prove that persistent collections maintained by TOB are able to be filtered by application logic. (Though the filter logic is as simple as judging the gender of a person, more complex criteria will work the same way.) A simple demo of TOB persistent programming: Class Person: @MakeSwappable public class Person extends TheObject { @Kin(iAm = "child") protected Father father; @Kin(iAm = "child") protected Mother mother; @Kin(iAm = { "father", "mother" }, theyAre = "child") protected final Set children = new TreeSet( new ChildComparator()); @Kin(iAm = { "father", "mother" }) protected final Set sons = new TreeSet(new ChildComparator()) { private static final long serialVersionUID = 1L; public boolean add(Child c) { if (c.o.gender != Gender.MALE) return false; return super.add(c); } }; @Kin(iAm = { "father", "mother" }) protected final Set daughters = new TreeSet( new ChildComparator()) { private static final long serialVersionUID = 1L; public boolean add(Child c) { if (c.o.gender != Gender.FEMALE) return false; return super.add(c); } }; @Kin(iAm = { "husband", "wife" }, thisIs = { "wife", "husband" }) protected Spouse spouse; public Person() { birthday = new Date(); name = new Name(); } public Spouse getSpouse() { return spouse; } public Father getFather() { return father; } public Mother getMother() { return mother; } public Set getChildren() { return children; } public Set getSons() { return sons; } public Set getDaughters() { return daughters; } private static class ChildComparator implements Comparator { public int compare(Child c1, Child c2) { return (int) (c2.o.birthday.getTime() - c1.o.birthday.getTime()); } } } Class Marriage: @MakeSwappable public class Marriage extends TheRelation { abstract public class Spouse extends Role { protected Spouse(Persistent<!--? extends Person--> person) { super(person); } } public class Husband extends Spouse { protected Husband(Persistent<!--? extends Person--> man) { super(man); } } public class Wife extends Spouse { protected Wife(Persistent<!--? extends Person--> woman) { super(woman); } } @Tie protected Husband husband; @Tie protected Wife wife; public Marriage(Persistent man, Persistent woman) { assert man != null : "Who is marrying noman?"; assert woman != null : "Who is marrying nowoman?"; this.husband = new Husband(man); this.wife = new Wife(woman); } protected Marriage() { } @Retying( { "husband", "wife" }) public void newPair(Persistent husband, Persistent wife) { this.husband = new Husband(husband); this.wife = new Wife(wife); } public Husband getHusband() { return husband; } public Wife getWife() { return wife; } } Class Parentage: @MakeSwappable public class Parentage extends TheRelation { public class Father extends Role { protected Father(Persistent<!--? extends Person--> p) { super(p); } } public class Mother extends Role { protected Mother(Persistent<!--? extends Person--> p) { super(p); } } public class Child extends Role { protected Child(Persistent<!--? extends Person--> p) { super(p); } } @Tie protected Father father; @Tie protected Mother mother; @Tie protected Child child; public Parentage(Persistent father, Persistent mother, Persistent child) { assert father != null : "Who can make children without a father?"; assert mother != null : "Who can make children without a mother?"; assert child != null : "No child, no parent!"; this.father = new Father(father); this.mother = new Mother(mother); this.child = new Child(child); } protected Parentage() { } @Retying( { "father", "mother" }) public void adoptBy(Persistent newFather, Persistent newMother) { this.father = new Father(newFather); this.mother = new Mother(newMother); } @Retying("child") public void changeChild(Persistent child) { this.child = new Child(child); } public Child getChild() { return child; } public Mother getMother() { return mother; } public Father getFather() { return father; } }

    Threaded Messages (45)

  2. There are no XML maps, no DDLs, no SQLs outside your Java code (SQL needs have been fairly reduced, but find persistent objects with SQL whenever needed), and SQL criteria are automatically generated as class fields at compilation
    So if I want to run my application on MySQL AND Postgresql I have to create 2 sets of code ? or is the mapping done for me? There is no DDL? so how do i map to my exact table definition (that already exists) ? Why *exactly* should I use this instead of a standardised interface like JDO2 or JPA1 ? which have code generation tools available for them, are standard, have multiple implementations available,
  3. However, ORM should be taken as a workaround after you learned a true Object Oriented Persistent Data Model
    So why not use JDO, which already allows the same data model to use ORM or object databases - no work-around.
    The currently supported RDBs are: * H2 Database Engine (by default shipped with WoW) * MySQL * PostgreSQL * Hypersonic SQL Database * Oracle
    JPOX, a good JDO 2.0 implementation, supports: H2, MySQL, PostgreSQL, Hypersonic, Oracle, MS SQL Server, Sybase, McKoi, Pointbase, Derby, DB2, Firebird, SAPDB/MaxDB, Informix
    (SQL needs have been fairly reduced, but find persistent objects with SQL whenever needed)
    Quality JDO/JPA implementations don't generate reduced SQL - they generate optimised, tuned SQL appropriate for each database.
    And you don't even need to create the db schema by yourself, just run your java program and tables get created underground.
    Just like the tools provided with many JDO/JPA implementations. For example JPOX's SchemaTool can be run standalone or within an application to do this.
    (Oracle is an exception, because it doesn't tolerate runtime schema changes, but SQL scripts will be generated for Oracle that can be simply run before the Java application runs.)
    No such distinction is required for any JDO product I have used - everything works for Oracle as for any other database. I use the same tools in the same way for schema generation.
    The spouse field of each newlywed will get automatically filled by TOB. And when current transaction get committed, it goes permanent.
    Transparent persistence; just as in JDO and JPA, with the different that in JDO and JPA this process can be tuned.
    like the Object/Relation/Kin (ORK) model behind TOB. Things will never get simplified enough until the Persistent Object Topography is expressed in native OO semantics.
    Just like already happens in JDO, although in JDO even the querying can be expressed in OO semantics in JDOQL, unlike here.
  4. However, ORM should be taken as a workaround after you learned a true Object Oriented Persistent Data Model


    So why not use JDO, which already allows the same data model to use ORM or object databases - no work-around.
    Besides the simplier data model, TOB is distinguished by its extreme performance as well, and anyone is free to beat it in benchmarks if like. TOB's official benchmark result is at: http://tob.ableverse.org/benchmarks.html while the source code also there. And is JDO model really as simple as TOB's to use? For example, to express the demo model in this article?
    The currently supported RDBs are:
    * H2 Database Engine (by default shipped with WoW)
    * MySQL
    * PostgreSQL
    * Hypersonic SQL Database
    * Oracle


    JPOX, a good JDO 2.0 implementation, supports:

    H2,
    MySQL,
    PostgreSQL,
    Hypersonic,
    Oracle,
    MS SQL Server,
    Sybase,
    McKoi,
    Pointbase,
    Derby,
    DB2,
    Firebird,
    SAPDB/MaxDB,
    Informix
    Yes, TOB's current list is quite short, it'll be increased on community demand. And I would restate: TOB is itself a database, not a mapper.
    (SQL needs have been fairly reduced, but find persistent objects with SQL whenever needed)
    Quality JDO/JPA implementations don't generate reduced SQL - they generate optimised, tuned SQL appropriate for each database.
    Here may be a misunderstanding or mistelling, what I mean by "SQL needs have been fairly reduced" is that many SQL statements have to be generated and sent are eliminated by the use of TOB, instead applications make only method calls to retrieve data previousely relied on querys.
    And you don't even need to create the db schema by yourself, just run your java program and tables get created underground.


    Just like the tools provided with many JDO/JPA implementations. For example JPOX's SchemaTool can be run standalone or within an application to do this.
    With TOB you even don't need such a tool, just .java source files, compile, and run.
    (Oracle is an exception, because it doesn't tolerate runtime schema changes, but SQL scripts will be generated for Oracle that can be simply run before the Java application runs.)


    No such distinction is required for any JDO product I have used - everything works for Oracle as for any other database. I use the same tools in the same way for schema generation.
    This could simply because you have a separated step to generate schema by tool. With Oracle the generated .sql script does exactly the same job. TOB has eliminated this step for all other RDB backends, while this Oracle exception is also hopefully to be solved in the future.
    The spouse field of each newlywed will get automatically filled by TOB. And when current transaction get committed, it goes permanent.


    Transparent persistence; just as in JDO and JPA, with the different that in JDO and JPA this process can be tuned.
    Something will be equal and some won't, and this needs detailed discussions.
    like the Object/Relation/Kin (ORK) model behind TOB. Things will never get simplified enough until the Persistent Object Topography is expressed in native OO semantics.


    Just like already happens in JDO, although in JDO even the querying can be expressed in OO semantics in JDOQL, unlike here.
    JDO spec is still obscure on relations, more specifically, the key function of a relation: to connect other persistent objects/relations are ignored by JDO. So JDO still belongs to a category of persistent systems which I'd call them "Plain OO without persistensive in mind that calls non-OO storages". The essential of Relational(Entity/Relation) Model is not the Entity(which is easier and JDO seems put most of its attention on this), but the Relation. Persistent objects are interconnected through Relations, NOT Through Plain Object References(in JDO thoughts). The interconnectivities among records are established in a logical manner in traditonal relational data systems, and they are so traversed through JOINed queries on-the-fly, this is quite suitable for disk targeted systems with limited main RAM size. After we got more RAM to play with, and adopted Object Oriented methodologies, we could seek performance and simplicity by presenting Persistent Object Topography in a physical manner, thus no query needed that more, it will be faster yet simpler to get related persistent objects via Direct Object References. But these Direct Object References are by no means the Plain ones JDO seems addressed. You have to take the Relation part into account as well. A simple challenge: Given a married person, he/she has a reference to his/her spouse (as the demo in the article). Then how do you get their marriage date as with JDO? If you have to turn the spouse reference in to a marriage reference, in order to get the marriage date easily, then time comes when you need to get the spouse, you have to first get the marriage object, then judge whether yourself is the husband or the wife, then get your spouse from another reference at the marriable object. Or are you going to maintain both a spouse reference and a marriage reference? I think this is both inelegance and afraid won't be guaranteed by JDO spec to be portable. Or you have another perfect solution? With TOB this is too easy, spouse.r(); is just the Marriage relation. I think this is the difference in Data Model between TOB and JDO. And for the query syntax, TOB doesn't itself support SQL, but by the abstract EngineRDB implementation of SwapEngine. All concrete SwapEngines ontop of RDBs are subclasses of EngineRDB. TOB itself is query mechanism neutral. If necessary JDO based SwapEngines could be implemented in the future, then you'll be able to query TOB persistent objects via JDOQL (though this seems not quite likely to happen).
  5. Besides the simplier data model, TOB is distinguished by its extreme performance as well, and anyone is free to beat it in benchmarks if like. TOB's official benchmark result is at: http://tob.ableverse.org/benchmarks.html while the source code also there. And is JDO model really as simple as TOB's to use? For example, to express the demo model in this article?
    I would say that it is.

    Here may be a misunderstanding or mistelling, what I mean by "SQL needs have been fairly reduced" is that many SQL statements have to be generated and sent are eliminated by the use of TOB, instead applications make only method calls to retrieve data previousely relied on querys.
    Sorry, I misunderstood. You also can retrieve data just by method calls in JDO. It is called transparent persistence.
    And you don't even need to create the db schema by yourself, just run your java program and tables get created underground.


    Just like the tools provided with many JDO/JPA implementations. For example JPOX's SchemaTool can be run standalone or within an application to do this.

    With TOB you even don't need such a tool, just .java source files, compile, and run. You don't need such a tool with JPOX either - just Java source files, and a single method call.
    (Oracle is an exception, because it doesn't tolerate runtime schema changes, but SQL scripts will be generated for Oracle that can be simply run before the Java application runs.)


    No such distinction is required for any JDO product I have used - everything works for Oracle as for any other database. I use the same tools in the same way for schema generation.

    This could simply because you have a separated step to generate schema by tool. With Oracle the generated .sql script does exactly the same job. TOB has eliminated this step for all other RDB backends, while this Oracle exception is also hopefully to be solved in the future.
    Note what I said about JPOX above. This may also be the case for other JDO implementations. No need for schema generation by a tool - can be done as program runs.


    Just like already happens in JDO, although in JDO even the querying can be expressed in OO semantics in JDOQL, unlike here.

    JDO spec is still obscure on relations, more specifically, the key function of a relation: to connect other persistent objects/relations are ignored by JDO.
    Sorry, but I just don't understand what you are saying here.
    So JDO still belongs to a category of persistent systems which I'd call them "Plain OO without persistensive in mind that calls non-OO storages".
    JDO works fine with OO storage - it is neutral about the storage method.
    The essential of Relational(Entity/Relation) Model is not the Entity(which is easier and JDO seems put most of its attention on this), but the Relation. Persistent objects are interconnected through Relations, NOT Through Plain Object References(in JDO thoughts).
    The interconnectivities among records are established in a logical manner in traditonal relational data systems, and they are so traversed through JOINed queries on-the-fly, this is quite suitable for disk targeted systems with limited main RAM size.
    After we got more RAM to play with, and adopted Object Oriented methodologies, we could seek performance and simplicity by presenting Persistent Object Topography in a physical manner, thus no query needed that more, it will be faster yet simpler to get related persistent objects via Direct Object References.
    But these Direct Object References are by no means the Plain ones JDO seems addressed. You have to take the Relation part into account as well.

    A simple challenge:
    Given a married person, he/she has a reference to his/her spouse (as the demo in the article). Then how do you get their marriage date as with JDO?
    If you have to turn the spouse reference in to a marriage reference, in order to get the marriage date easily, then time comes when you need to get the spouse, you have to first get the marriage object, then judge whether yourself is the husband or the wife, then get your spouse from another reference at the marriable object.
    Or are you going to maintain both a spouse reference and a marriage reference? I think this is both inelegance and afraid won't be guaranteed by JDO spec to be portable.
    Or you have another perfect solution?
    With TOB this is too easy, spouse.r(); is just the Marriage relation.
    I think this is the difference in Data Model between TOB and JDO.

    And for the query syntax, TOB doesn't itself support SQL, but by the abstract EngineRDB implementation of SwapEngine. All concrete SwapEngines ontop of RDBs are subclasses of EngineRDB.
    TOB itself is query mechanism neutral. If necessary JDO based SwapEngines could be implemented in the future, then you'll be able to query TOB persistent objects via JDOQL (though this seems not quite likely to happen).
    This answer may not be a direct reponse to your comments if to, I am sorry, but I am having trouble following your English. In JDO you can set up whatever object model you like; there are few restrictions. Information is reached just by accessing objects through normal method calls. I could set up exactly the same data model as you have shown in JDO, but I would express the persistence relationships in a separate .JDO file (which, in my view, is better, as it keeps persistence information away from the data model). JDO also does not specify any need for use of relational stores. There is no reason why a JDO implementation should not use a pure in-memory store, and no reason why that implementation should have to use a series of relational queries to retrieve connected objects. I think the main point is that there are already extremely good persistence products in Java, which allow use of standard APIs. An increasing number of these are free and open source. The JDO implementations are very powerful and allow a pure object model, of whatever organision you like. There would have to be some major advantage for there to be take-up of any new approach to persistence, especially if it did not implement a standard API. All you seem to be saying here is that a pure RAM-based system which doesn't even attempt to connect to relational store is fast. That will obviously be the case.
  6. All you seem to be saying here is that a pure RAM-based system which doesn't even attempt to connect to relational store is fast. That will obviously be the case.
    This is one of the things that we are implementing for the next JPOX version. JPOX will carefully cache selected Sets used by queries (based on query plans and past execution) to perform in memory query evaluation. JPOX will evaluate queries as fast as your memory bus can handle :-) plus, queries can evaluated in different nodes and have cache distributed with products like Tangosol. I pretty much appreciate what has been done in TOB, however we have a standard API and mature runtime execution behavior called JDO, as well as extensible. Good luck --------------- Erik Bengtson, JPOX Java Persistent Objects - now flying :-)
  7. All you seem to be saying here is that a pure RAM-based system which doesn't even attempt to connect to relational store is fast. That will obviously be the case.


    This is one of the things that we are implementing for the next JPOX version. JPOX will carefully cache selected Sets used by queries (based on query plans and past execution) to perform in memory query evaluation.

    JPOX will evaluate queries as fast as your memory bus can handle :-) plus, queries can evaluated in different nodes and have cache distributed with products like Tangosol.

    I pretty much appreciate what has been done in TOB, however we have a standard API and mature runtime execution behavior called JDO, as well as extensible.

    Good luck

    ---------------
    Erik Bengtson, JPOX
    Java Persistent Objects - now flying :-)
    Thanks for the greeting Erik, I'm so happy that grabbed your attention here ;-) I had been disappointed by the JDO spec long ago, when I started to looking for a standard for persistency to follow. And TOB finally came out to be a RAM targeted (or based) persistent runtime, but it can provide full ACID at serializable isolation level, with even extreme performance. What's the key point, to be useful in real applications, opposing to something like Prevayler, TOB enables you to query persistent objects in RAM with the popular SQL language. And since Hibernate also do the *Smart Cache* in the benchmarks I done, but even 17 times slower than TOB. So I'm wondering even with the cache implemented, can the furture version of JPOX beat TOB's performance? This is because TOB's persistent objects are not cache at all, they are the canonical data piece, they are guaranteed by TOB to be Loaded (be set Online in TOB terms) with its full persistent topograph, before returned to the application code. And for the data model elegance, I wonder if you'd like to provide a JDO example comparable to the TOB demo model I posted in this article. Since you are a JDO expert, it's should be fair (I'm the TOB expert of coz). - Compl (http://www.ableverse.org - Programming By Nature)
  8. This answer may not be a direct reponse to your comments if to, I am sorry, but I am having trouble following your English.

    In JDO you can set up whatever object model you like; there are few restrictions. Information is reached just by accessing objects through normal method calls. I could set up exactly the same data model as you have shown in JDO, but I would express the persistence relationships in a separate .JDO file (which, in my view, is better, as it keeps persistence information away from the data model).

    JDO also does not specify any need for use of relational stores. There is no reason why a JDO implementation should not use a pure in-memory store, and no reason why that implementation should have to use a series of relational queries to retrieve connected objects.

    I think the main point is that there are already extremely good persistence products in Java, which allow use of standard APIs. An increasing number of these are free and open source. The JDO implementations are very powerful and allow a pure object model, of whatever organision you like.

    There would have to be some major advantage for there to be take-up of any new approach to persistence, especially if it did not implement a standard API.

    All you seem to be saying here is that a pure RAM-based system which doesn't even attempt to connect to relational store is fast. That will obviously be the case.
    I would say sorry to all ever suffered from my English, sorry! Excuse me, my English is learned in China... After all these discussions, isn't it better to have a runnable demo in JDO (JPOX) model compared to the demo in this article? But seems TSS isn't such an arena, any suggestion?
  9. There are no XML maps, no DDLs, no SQLs outside your Java code (SQL needs have been fairly reduced, but find persistent objects with SQL whenever needed), and SQL criteria are automatically generated as class fields at compilation

    So if I want to run my application on MySQL AND Postgresql I have to create 2 sets of code ? or is the mapping done for me? There is no DDL? so how do i map to my exact table definition (that already exists) ?
    If you supply no option to TOB APT processor when compiling the Java source code, by default TOB generate stub classes for all known SwapEngine(RDB in backend)s, this is the way WoW releases are compiled. So which RDB to use can be dynamically chose at runtime. Of course you can specify a target engine list for TOB to only generate supporting classes for them. TOB will compare your persistent java classes' persistent fields to the underlying RDB schema at runtime, unless incompatible column types were found, or TOB was told no to change db schema automatically (by conf), TOB will generate SQL scripts to align the db schema with your persistent java classes onfly, then try to execute them. If no problem occur, your programm continue to run. So to use existing table definitions, just write your persistent java class with compatible persistent fields.
    Why *exactly* should I use this instead of a standardised interface like JDO2 or JPA1 ? which have code generation tools available for them, are standard, have multiple implementations available,
    There can be 2 major reasons: performance and simplicity. I don't know why TSS Editor cut the benchmark links from my original post, it's here: http://tob.ableverse.org/benchmarks.html It should be quite legal IMO, and it is a big part of what TOB means. TOB is distinguished from other DBMS for its extreme performance. This has been the key reason that WoW able to come true. WoW's security system performs intensive checks those can be tens of SQL statements sent to retrieve a single node, while each WoW client may request tens of nodes in one second. But with TOB, it needs none SQL at all, just traverse persistent structures of the persistent objects. Due to the benchmarks, you can see with Hibernate even all data has been in cache (read hot), it still needs 18 times of TOB cost to accomplish. But the benchmarks havn't been done with any JDO implementation, if you think one could beat TOB then let's try it out. The bench source code is free to download. JDO and JPA have code generation tools as you pointed out, but you don't even need one with TOB, you just write your .java files, compile, and done. Isn't this simpler?
  10. If you supply no option to TOB APT processor when compiling the Java source code, by default TOB generate stub classes for all known SwapEngine(RDB in backend)s, this is the way WoW releases are compiled. So which RDB to use can be dynamically chose at runtime. Of course you can specify a target engine list for TOB to only generate supporting classes for them. TOB will compare your persistent java classes' persistent fields to the underlying RDB schema at runtime, unless incompatible column types were found, or TOB was told no to change db schema automatically (by conf), TOB will generate SQL scripts to align the db schema with your persistent java classes onfly, then try to execute them. If no problem occur, your programm continue to run. So to use existing table definitions, just write your persistent java class with compatible persistent fields.
    Ahhh, so I have to supply mapping information then if I want to match to an existing schema. OK, glad we got that clear. You can word it however you want, and as wordy as you want but the end result is the same. In many situations a schema on Postgres, MSSQL, Oracle, Sybase all have their own oddities. Consequently you *need* mapping information to match to the individual oddities. It is unwise to play around with your class whenever you want to map to a different datastore (because then it will no longer map to your current datastore). Thanks for your wordy description but sadly you dont express anything in the terms that end users require and so however good or not your ideas and software you wont attract users. Adding various personal acronyms doesn't impress. I'll stick to standard established persistence mechanisms rather than custom mapping that claims to be n times faster than JDBC. Been there before I think on TSS. Is that you Ward Mullins ?
  11. It is unwise to play around with your class whenever you want to map to a different datastore (because then it will no longer map to your current datastore).
    One of the best things about having information in external files (such as JDO's .jdo and .orm files) is that you don't need to touch your Java code. You can have a customised .orm optimised for any particular database engine. You can put off selecting the database until run-time by supplying properties specifying the database to a JDOHelper method. No need to generate stub classes or re-combile Java code. This means you can easily use JDO to work with existing data models even those for which you don't have the source code.
  12. It is unwise to play around with your class whenever you want to map to a different datastore (because then it will no longer map to your current datastore).


    One of the best things about having information in external files (such as JDO's .jdo and .orm files) is that you don't need to touch your Java code. You can have a customised .orm optimised for any particular database engine. You can put off selecting the database until run-time by supplying properties specifying the database to a JDOHelper method. No need to generate stub classes or re-combile Java code. This means you can easily use JDO to work with existing data models even those for which you don't have the source code.
    Okay, my post above explains in fact you do NOT need to *play around with your class*. Which seems misunderstood in lacks of my coverage. And for optimisation, a RAM targeted OO persistent model over a disk targeted non-OO model will do the trick on overwhelming performance boost. TOB is a new database, not just another OR-Mapper.
  13. It is unwise to play around with your class whenever you want to map to a different datastore (because then it will no longer map to your current datastore).


    One of the best things about having information in external files (such as JDO's .jdo and .orm files) is that you don't need to touch your Java code. You can have a customised .orm optimised for any particular database engine. You can put off selecting the database until run-time by supplying properties specifying the database to a JDOHelper method. No need to generate stub classes or re-combile Java code. This means you can easily use JDO to work with existing data models even those for which you don't have the source code.

    Okay, my post above explains in fact you do NOT need to *play around with your class*. Which seems misunderstood in lacks of my coverage.

    And for optimisation, a RAM targeted OO persistent model over a disk targeted non-OO model will do the trick on overwhelming performance boost. TOB is a new database, not just another OR-Mapper.
    In a post above you mentioned including an annotation @TypeSpec. Suppose requirements for the persistence store changed? Say, you needed to change the precision? You would have to change this in the Java source and recompile. In JDO it is a change in a configuration file (.jdo or .orm). No need to recompile. Even better, you can retain different mappings for different stores and select the mapping at run-time. It is far from unknown for two different stores to require different mappings. In MySQL you can specify two or more TEXT columns in the same table. In Oracle, you can't have more than one LONG column in each table. It can be hard to find a common set of mappings. Suppose you have two columns which you want to store strings of length greater than 255 in MySQL pre 5.0 and Oracle. In MySQL you will have to declare two TEXT columns. In Oracle you will have to use, say, one varchar2 and one LONG. This is going to be a problem to express as just one set of annotations in a Java class. In JDO (and JPA) you can have all these differences outside the Java code, expressed in mapping files. And, as I said, there is nothing to stop a JDO implementation from running on a RAM-targetted model.
  14. In a post above you mentioned including an annotation @TypeSpec. Suppose requirements for the persistence store changed? Say, you needed to change the precision? You would have to change this in the Java source and recompile. In JDO it is a change in a configuration file (.jdo or .orm). No need to recompile. Even better, you can retain different mappings for different stores and select the mapping at run-time. It is far from unknown for two different stores to require different mappings. In MySQL you can specify two or more TEXT columns in the same table. In Oracle, you can't have more than one LONG column in each table. It can be hard to find a common set of mappings. Suppose you have two columns which you want to store strings of length greater than 255 in MySQL pre 5.0 and Oracle. In MySQL you will have to declare two TEXT columns. In Oracle you will have to use, say, one varchar2 and one LONG.

    This is going to be a problem to express as just one set of annotations in a Java class. In JDO (and JPA) you can have all these differences outside the Java code, expressed in mapping files.

    And, as I said, there is nothing to stop a JDO implementation from running on a RAM-targetted model.
    I think you'll aggree that in the java classes, persistent info should be abstract, and handled differently for different physical datastores. TOB SwapEngines do the dirty jobs you mentioned by maintaining the mapping conf files manually, while the difference is SwapEngines do this automatically, systematically, and are to be optimized by focused experts. I see JDO spec is rather obscure itself for the guarantee of full-RAM-class performance. While TOB is just this thing, not other things.
  15. I think you'll aggree that in the java classes, persistent info should be abstract, and handled differently for different physical datastores. TOB SwapEngines do the dirty jobs you mentioned by maintaining the mapping conf files manually, while the difference is SwapEngines do this automatically, systematically, and are to be optimized by focused experts.
    So how would I specify, using annotations in a single Java class, or some other method, that I wanted two fields in that class persisted as strings of length, say, 2000 chars, in a way that would work for MySQL 4.1 and Oracle? This is something I am having to deal with in a current project.
  16. I think you'll aggree that in the java classes, persistent info should be abstract, and handled differently for different physical datastores. TOB SwapEngines do the dirty jobs you mentioned by maintaining the mapping conf files manually, while the difference is SwapEngines do this automatically, systematically, and are to be optimized by focused experts.


    So how would I specify, using annotations in a single Java class, or some other method, that I wanted two fields in that class persisted as strings of length, say, 2000 chars, in a way that would work for MySQL 4.1 and Oracle? This is something I am having to deal with in a current project.
    Okay, I havn't noticed much about this LONG/TEXT column issue, I'd assumed standard SQL semantics in TOB's development till now. In case you have such a project now, I'd like to write the TOB model for your project, and make it run for both MySQL and Oracle, only if you feel appropriate to share your model to me. I take this as a chance to valiate TOB's production quality, maybe need real enhancements, but I'd like to provide this effort for TOB to fulfill such situations. If you'd like, contact me at complystill(A T)yahoo.com.cn I'm also glad to be banged through Y!M under the same yahoo id.
  17. I think you'll aggree that in the java classes, persistent info should be abstract, and handled differently for different physical datastores. TOB SwapEngines do the dirty jobs you mentioned by maintaining the mapping conf files manually, while the difference is SwapEngines do this automatically, systematically, and are to be optimized by focused experts.


    So how would I specify, using annotations in a single Java class, or some other method, that I wanted two fields in that class persisted as strings of length, say, 2000 chars, in a way that would work for MySQL 4.1 and Oracle? This is something I am having to deal with in a current project.

    Okay, I havn't noticed much about this LONG/TEXT column issue, I'd assumed standard SQL semantics in TOB's development till now.
    In case you have such a project now, I'd like to write the TOB model for your project, and make it run for both MySQL and Oracle, only if you feel appropriate to share your model to me.
    I take this as a chance to valiate TOB's production quality, maybe need real enhancements, but I'd like to provide this effort for TOB to fulfill such situations.

    If you'd like, contact me at complystill(A T)yahoo.com.cn
    I'm also glad to be banged through Y!M under the same yahoo id.
    I am afraid that the project is private, we are already substantially down the JDO route, and we have a requirement for integration with substantial legacy schemas, so I can't offer you the model. But what I can say is that sooner or later in any major persistence project you discover that SQL 'standards' aren't that standard! (Incidentally, this is why I feel cautious about any persistence solution that uses only SQL and not a portable query language). I think that if you have a high-performance way of 'persisting' objects to memory, it would be a really great idea to try implementing it using an existing persistence API; JDO sounds ideal. The reason is that you aren't having to re-invent the wheel in terms of mapping or querying. A wonderful thing about JDO is its independence from the persistence mechanism. If a fast in-memory store had a JDO interface, I would definitely want to evaluate it - I can see real uses, such as very-high-speed querying of read-only data.
  18. I am afraid that the project is private, we are already substantially down the JDO route, and we have a requirement for integration with substantial legacy schemas, so I can't offer you the model.

    But what I can say is that sooner or later in any major persistence project you discover that SQL 'standards' aren't that standard! (Incidentally, this is why I feel cautious about any persistence solution that uses only SQL and not a portable query language).

    I think that if you have a high-performance way of 'persisting' objects to memory, it would be a really great idea to try implementing it using an existing persistence API; JDO sounds ideal. The reason is that you aren't having to re-invent the wheel in terms of mapping or querying. A wonderful thing about JDO is its independence from the persistence mechanism. If a fast in-memory store had a JDO interface, I would definitely want to evaluate it - I can see real uses, such as very-high-speed querying of read-only data.
    That's alright. TOB is also best at new projects, porting or inherit legacy schema will be real headache as well. What TOB brings is OO centric persistent design, by eliminating as many relational approaches as possible. Under no particular preference against a RDB, user are better to choose a SwapEngine best suit TOB's SQL requirements. Anyway, this could not be quite possible for legacy projects. TOB is a new thing itself, so is best used as a fresh new db at its own best choice of SwapEngines. What's my opnion on JDO is that it is less pleasing, it never elimites much of the complexities inherited from non-OO persistent approaches. So is with EJB3 aka JPA. I hates the whole minds about one-to-one, one-to-many, or many-to-many relation terms as the design burden, things could be far simpler. In TOB's design approach, you only need to think about whether it is a single reference or a collection of references you wang to keep at your class, set yourself free from writing what called *one-to-one* or *one-to-many* or *many-to-many* mappings.
  19. Ahhh, so I have to supply mapping information then if I want to match to an existing schema. OK, glad we got that clear. You can word it however you want, and as wordy as you want but the end result is the same. In many situations a schema on Postgres, MSSQL, Oracle, Sybase all have their own oddities. Consequently you *need* mapping information to match to the individual oddities. It is unwise to play around with your class whenever you want to map to a different datastore (because then it will no longer map to your current datastore).
    I got your point now. Let me make the mapping part explicitly clear, for your doubt here: that the *mapping* information need to be on the java source files are universal uniform, and *oddities* between the datastores are handled by their respecitve SwapEngine implementations, such as EngineMySQL, EngineH2DB, EnginePgSQL, EngineHSQL, EngineORA. And once a SwapEngine has its supporting classes generated, it can be used at runtime. And just switch datastores with only changing the SwapEngine name and JDBC url (No change to java files, no recompile). Application Java class sources know nothing about the *oddities*. For example, if you have a String field annotated with @TypeSpec(precision=200), it will be translated to TINYTEXT by EngineMySQL, VARCHAR2(200) by EngineORA, and VARCHAR(200) by EnginePgSQL. All this at runtime, and on-the-fly. Does this lighten your worry?
    Thanks for your wordy description but sadly you dont express anything in the terms that end users require and so however good or not your ideas and software you wont attract users. Adding various personal acronyms doesn't impress. I'll stick to standard established persistence mechanisms rather than custom mapping that claims to be n times faster than JDBC. Been there before I think on TSS. Is that you Ward Mullins ?
    And thanks for your clue about this issue that awoke me to make it clear. Hope my explaination here get you feel a little comforter with TOB. BTW, with TOB, the schema design should be OO central at best, I mean all design in Java classes, persistent fields and interrelations. Porting existing schemas to TOB will be harder.
  20. BTW, with TOB, the schema design should be OO central at best, I mean all design in Java classes, persistent fields and interrelations. Porting existing schemas to TOB will be harder.
    Having the ability to express field information (such as precision) in external configuration files is a great help to porting existing schemas. It also allows changes in schema without requiring re-compilation. Personally, I really don't like the idea of mapping information embedded in source files (although many don't share this view).
  21. BTW, with TOB, the schema design should be OO central at best, I mean all design in Java classes, persistent fields and interrelations. Porting existing schemas to TOB will be harder.


    Having the ability to express field information (such as precision) in external configuration files is a great help to porting existing schemas. It also allows changes in schema without requiring re-compilation. Personally, I really don't like the idea of mapping information embedded in source files (although many don't share this view).
    Of course, don't you see the @TypeSpec(precision=200) example in the post you are quoting? But if you don't have a persistent field in java, how could it be used in an OO way after a db column has been added without recompilation?
  22. Of course, don't you see the @TypeSpec(precision=200) example in the post you are quoting?

    But if you don't have a persistent field in java, how could it be used in an OO way after a db column has been added without recompilation?
    Oh! Sorry for my misunderstanding here, you mean *in external conf file*. TOB won't complain and continue to run as normal unless you shinked the precision of a column in db. In this case TOB will try to stretch it back. TOB will work without recompilation when you defined the precision=200 in java, and further extend it to 4000 in db.
  23. I got your point now. Let me make the mapping part explicitly clear, for your doubt here: that the *mapping* information need to be on the java source files are universal uniform, and *oddities* between the datastores are handled by their respecitve SwapEngine implementations, such as EngineMySQL, EngineH2DB, EnginePgSQL, EngineHSQL, EngineORA. And once a SwapEngine has its supporting classes generated, it can be used at runtime. And just switch datastores with only changing the SwapEngine name and JDBC url (No change to java files, no recompile). Application Java class sources know nothing about the *oddities*. For example, if you have a String field annotated with @TypeSpec(precision=200), it will be translated to TINYTEXT by EngineMySQL, VARCHAR2(200) by EngineORA, and VARCHAR(200) by EnginePgSQL. All this at runtime, and on-the-fly.

    Does this lighten your worry?
    There are far more differences between RDBMS and schema mapping than the type of a field. Nullability, column name, default value, restricting the values (CHECK clause), names of constraints, etc etc. This goes on. What you keep referring to as "EngineXXX" has a direct equivalent in all JDO/JPA implementations i've seen. They do the simple stuff for me now. What they also allow is the detailed differences and allow me to specify mapping files. You dont allow that seemingly (thinking that it isnt necessary).
  24. There are far more differences between RDBMS and schema mapping than the type of a field. Nullability, column name, default value, restricting the values (CHECK clause), names of constraints, etc etc. This goes on. What you keep referring to as "EngineXXX" has a direct equivalent in all JDO/JPA implementations i've seen. They do the simple stuff for me now. What they also allow is the detailed differences and allow me to specify mapping files. You dont allow that seemingly (thinking that it isnt necessary).
    Yes, you are right, TOB doesn't allow this sort of tweaks. SwapEngine is nothing new in concept, does this matter? But think of TOB as an standalone database itself. Why it stores physical data to RDBs is to treasure and value RDB's indexed query ability, more interfaces to different languages, and backup/maintenance tools. And for other things, don't you think Java is more powerful than Stored Procedures? Or non-standard CHECK syntax provided differently by different RDB vendors? With TOB, you do all things other than standard SQL queries in Java, an OO language infrasture, which is more powerful and standardlized than the Procedural Language.
  25. And for other things, don't you think Java is more powerful than Stored Procedures? Or non-standard CHECK syntax provided differently by different RDB vendors?

    With TOB, you do all things other than standard SQL queries in Java, an OO language infrasture, which is more powerful and standardlized than the Procedural Language.
    I agree, but with JDO you not only get the ability to do things in pure Java, but you also get a query language that is OOP (unlike SQL) and data-store independent. The same query language works with XML, LDAP, Relational stores, object stores and in-memory stores.
  26. I agree, but with JDO you not only get the ability to do things in pure Java, but you also get a query language that is OOP (unlike SQL) and data-store independent. The same query language works with XML, LDAP, Relational stores, object stores and in-memory stores.
    How is:
    Collection> emps = tob.querier.query(Employee.class, 1, // start at 0, // max to return EmployeeQ.DEPT$NAME + " = ?", "R&D");
    compared to:
    Class empClass = Employee.class; Extent clnEmployee = pm.getExtent (empClass, false); String filter = "dept.name == dep"; String param = "String dep"; Query q = pm.newQuery (clnEmployee, filter); q.declareParameters (param); String rnd = "R&D"; Collection emps = (Collection) q.execute (rnd);
    I like the first one. Obviously this needs a JOIN on a relational storage, and TOB will issue this JOIN when depetartment criteria such as DEPT$NAME are detected. Other times if only criteria on Employee are specified, TOB will not issue the JOIN to save performance.
  27. I agree, but with JDO you not only get the ability to do things in pure Java, but you also get a query language that is OOP (unlike SQL) and data-store independent. The same query language works with XML, LDAP, Relational stores, object stores and in-memory stores.


    How is:
    Collection> emps =
    tob.querier.query(Employee.class,
    1, // start at
    0, // max to return
    EmployeeQ.DEPT$NAME + " = ?",
    "R&D");

    compared to:
    Class empClass = Employee.class;
    Extent clnEmployee = pm.getExtent (empClass, false);
    String filter = "dept.name == dep";
    String param = "String dep";
    Query q = pm.newQuery (clnEmployee, filter);
    q.declareParameters (param);
    String rnd = "R&D";
    Collection emps = (Collection) q.execute (rnd);


    I like the first one. Obviously this needs a JOIN on a relational storage, and TOB will issue this JOIN when depetartment criteria such as DEPT$NAME are detected. Other times if only criteria on Employee are specified, TOB will not issue the JOIN to save performance.
    The JDO 1.0 API was definitely verbose. Now in JDO 2.0 you can do: Query q = pm.newQuery(Employee.class,"dept.name == :dep"); Collection emps = (Collection) q.execute("R&D"); And, there is only a requirement for a join if the JDO implementation is working directly with a relational store.
  28. Now in JDO 2.0 you can do:


    Query q = pm.newQuery(Employee.class,"dept.name == :dep");
    Collection emps = (Collection) q.execute("R&D");


    And, there is only a requirement for a join if the JDO implementation is working directly with a relational store.
    Did you miss something? I can't figure out how "R&D" is associated with :dep.
  29. Now in JDO 2.0 you can do:


    Query q = pm.newQuery(Employee.class,"dept.name == :dep");
    Collection emps = (Collection) q.execute("R&D");


    And, there is only a requirement for a join if the JDO implementation is working directly with a relational store.

    Did you miss something? I can't figure out how "R&D" is associated with :dep.
    Position in the argument list. There is one parameter ':dep', and one argument to execute - "R&D". in JDO 2.0 you can have up to 3 parameters specified directly. If more than 3 then you can pass an Array of values (where position in the array corresponds to parameter number), or a Map where the keys are the parameter names in the queries.
  30. or a Map where the keys are the parameter names in the queries.
    Incidentally, this is one way that Groovy works very nicely with JDO, as it has a special syntax for Maps.
  31. Position in the argument list. There is one parameter ':dep', and one argument to execute - "R&D".

    in JDO 2.0 you can have up to 3 parameters specified directly. If more than 3 then you can pass an Array of values (where position in the array corresponds to parameter number), or a Map where the keys are the parameter names in the queries.
    Okay, just downloaded, but I did find this syntax in 14.10 Query -> Examples: section of the final JDO 2.0 spec. Anyway, it's no hard to be wrapped like this. But till now no one has provided a data model in other products - JDO, JPOX or JPA? which is comparable to my demo model in the article. Is it that hard?
  32. Wanna Rock?[ Go to top ]

    For people who will have fun in beating TOB or me, come get some! I challenge you with porting the WoW project (http://wow.dev.java.net) to your favoriate persistent platforms, JDO, JPA, Hiberante, JDBC, or even Prevalyer! Don't you like brain storming with people from allover the world? WoW will give you a rock! And why not create your own version of it when you have chance? -Compl (http://www.ableverse.org - Programming By Nature)
  33. Re: Wanna Rock?[ Go to top ]

    Do I understand you right, that on application startup TOB will load all data from a relational database in to the RAM and when I update or insert new data, it will be stored again on the relational database. Are there any tutorials available how it works? Reto
  34. Re: Wanna Rock?[ Go to top ]

    Do I understand you right, that on application startup TOB will load all data from a relational database in to the RAM and when I update or insert new data, it will be stored again on the relational database. Are there any tutorials available how it works?

    Reto
    Okay, the procedure can be described clearly, as this: Every persistent objects under management of TOB has a priority number - OnlinePriority (default value defined at class level, and changable after birth). TOB has a config option of the target percentage of RAM it should try to use. TOB is started when application code invokes to create an instance of it. On creation, TOB starts by comparing the underlying RDB's schema against all persistent classes ever compiled, try to align them if not consistent. After the DB schema is believed ready to serve all persistent classes. TOB starts loading persistent objects regarding their OnlinePriority, the higher the priority (smaller the number) is, the prior to be set online. This provides some bit of managable QualityOfService. TOB will keep loading objects until it found free RAM percentage has droped to/under the configured value, or all objects have been loaded (set online). Then control will be given back to the application creating the TOB instance. Once TOB loads a persistent object, it insists to load all other related objects physically connected to that object, it will not stop with only partial of that object's topograph loaded (in TOB's term, the state of LOADED, but not ONLINE). So until an object is fully *Set Online*, TOB will not check the free RAM condition, and OutOfMemoryError can occur. So you should carefully design your persistent topography, that the largest isolated physical segment never exceeds your RAM size. For segments never referenced by application code, they'll be *swapped out* by java garbage collector since TOB's references to them are all WeakReferences. Unused persistent objects will give room to those need to be loaded. Whether objects are *physically* connected due to the persistent class semantics at design time, that if you want one or some related objects be physically connected to an instance of a persistent class, define a Persistent reference or a collection of them at your persistent class and annotate it with @Kin. While they can always be logically connected via key values like in the relational model. Is this clear enough?
  35. Re: Wanna Rock?[ Go to top ]

    For people who will have fun in beating TOB or me
    People on this thread have been trying to assertain *what* your system does because the description does not read well. It reads that you are comparing the persistence to MySQL with JDBC against your system doing the same. Unfortunately you are not doing that and you are comparing full persistence to a datastore with storage in memory which is a comparison of apples with oranges ... both are fruit but thats as far as the comparison can go. This is presumably why TSS didnt post your "benchmark" link ... since it is not a comparison that will interest its users. There are already existing standards and people use them, so people naturally compare against them. These "standards" are open for others to contribute if they have good ideas. That is not beating up you or your system. Its extracting the necessary information to make a judgement.
    I challenge you with porting the WoW project
    So you want people to spend their spare time porting some beta-quality software (see the web page you linked to), that the vast majority of people have never even heard of, to their persistence framework of choice just to satisfy *your* needs ? The term selfish springs to mind there.
  36. Re: Wanna Rock?[ Go to top ]

    For people who will have fun in beating TOB or me

    People on this thread have been trying to assertain *what* your system does because the description does not read well. It reads that you are comparing the persistence to MySQL with JDBC against your system doing the same. Unfortunately you are not doing that and you are comparing full persistence to a datastore with storage in memory which is a comparison of apples with oranges ... both are fruit but thats as far as the comparison can go. This is presumably why TSS didnt post your "benchmark" link ... since it is not a comparison that will interest its users.
    Okay, I can accept this because TOB's performance boost is really hard to believe. But I would argue that as db4o and Hibernate were also included in my benchmarks, they also heavily use RAM cache/optimizations, just less effecient than TOB does.
    There are already existing standards and people use them, so people naturally compare against them. These "standards" are open for others to contribute if they have good ideas. That is not beating up you or your system. Its extracting the necessary information to make a judgement.
    I challenge you with porting the WoW project

    So you want people to spend their spare time porting some beta-quality software (see the web page you linked to), that the vast majority of people have never even heard of, to their persistence framework of choice just to satisfy *your* needs ? The term selfish springs to mind there.
    Okay, sorry for the aggressive words I'd used here. Don't do that if you don't like. And as a little tip: Are you aware that WoW is the world's first *Web Based* Mind Mapping software?
  37. Re: Wanna Rock?[ Go to top ]

    Okay, sorry for the aggressive words I'd used here.
    Don't do that if you don't like.

    And as a little tip: Are you aware that WoW is the world's first *Web Based* Mind Mapping software?
    Don't worry about it. Some people still think that the world is flat and the Sun moves around the Earth. :) It looks like a good idea. I'm pretty sure that anyone who is either tired of being tied to relational databases or doesn't need to interact with legacy anything could use it one day, but the API and annotations seem annoying. I don't see why everyone is in such an uproar because there's another [possibly good] alternative challenging their craptastic legacy data model and APIs which are really just bandaids. Oh, that's right! It's fear of change and things that are different. Nevermind! As good as your idea may be, you have a lot of work ahead to prove it. All the best!
  38. Re: Wanna Rock?[ Go to top ]

    It looks like a good idea. I'm pretty sure that anyone who is either tired of being tied to relational databases or doesn't need to interact with legacy anything could use it one day, but the API and annotations seem annoying. I don't see why everyone is in such an uproar because there's another [possibly good] alternative challenging their craptastic legacy data model and APIs which are really just bandaids.
    I don't think things are like that at all. My caution about this is that there is already a well-established API for general object persistence in Java - JDO. The JDO API is full-featured and is not tied to relational databases. It has a query language designed to express things in an OOP way. If you don't like the query language there is a standard way to plug in your own. So I don't see much point in this product having its own, new API. Because of that, it is likely to remain, for me, just an interesting idea. I will wait until something similar arises that has a JDO or JPA API; I suspect I won't have to wait long.
  39. Proof in JDO?[ Go to top ]

    I don't think things are like that at all. My caution about this is that there is already a well-established API for general object persistence in Java - JDO. The JDO API is full-featured and is not tied to relational databases. It has a query language designed to express things in an OOP way. If you don't like the query language there is a standard way to plug in your own. So I don't see much point in this product having its own, new API. Because of that, it is likely to remain, for me, just an interesting idea. I will wait until something similar arises that has a JDO or JPA API; I suspect I won't have to wait long.
    Hi Steve, in order that you believe JDO could do the same simple and elegance as TOB does, would you like defend your conclusion by providing a simple Person-Marriage-Parentage model in JDO? Even a simular is okay, I'm eager to see. You see its fairly easy in TOB, no more than 20 miniutes (for me 5 mins enough) to write out.
  40. Re: Proof in JDO?[ Go to top ]


    Hi Steve, in order that you believe JDO could do the same simple and elegance as TOB does, would you like defend your conclusion by providing a simple Person-Marriage-Parentage model in JDO? Even a simular is okay, I'm eager to see.

    You see its fairly easy in TOB, no more than 20 miniutes (for me 5 mins enough) to write out.
    I don't need to write anything out. The model in JDO is pretty the same as your model, although simpler. You don't need to extend TheObject, or use Persistent - your object model need contain no information about how or if it is persisted (that information is added by enhancement). You don't need any annotations. You simply express the relationship between classes by normal object references, so the JDO model would have exactly the same fields, collections, setters and getters. You then list the classes in the .JDO file, along with the types of members of collections. This would only be a few lines in your model. That is it. If you want to model things using some sort of 'Relation' object, that is entirely up to you - you can use whatever object model paradigm you like. This allows a data model to be written almost independently of persistence considerations (an advantage that JDO has over the current version of JPA).
  41. Re: Proof in JDO?[ Go to top ]

    I don't need to write anything out. The model in JDO is pretty the same as your model, although simpler. You don't need to extend TheObject, or use Persistent - your object model need contain no information about how or if it is persisted (that information is added by enhancement). You don't need any annotations. You simply express the relationship between classes by normal object references, so the JDO model would have exactly the same fields, collections, setters and getters. You then list the classes in the .JDO file, along with the types of members of collections. This would only be a few lines in your model. That is it. If you want to model things using some sort of 'Relation' object, that is entirely up to you - you can use whatever object model paradigm you like.

    This allows a data model to be written almost independently of persistence considerations (an advantage that JDO has over the current version of JPA).
    I don't think the model you described will directly run for you, even after JDO *enhancement*. But okay, I stop talk about this without a concrete persistent application in context.
  42. Re: Proof in JDO?[ Go to top ]

    I don't think the model you described will directly run for you, even after JDO *enhancement*. But okay, I stop talk about this without a concrete persistent application in context.
    Well, as others have posted, if you want to promote your product, you should come up with a concrete example in JDO yourself. There is already some JDO code in the poleposition examples.
  43. New Benchmarks?[ Go to top ]

    Well, as others have posted, if you want to promote your product, you should come up with a concrete example in JDO yourself. There is already some JDO code in the poleposition examples.
    Okay, thanks for this suggestion, I'm taking it. In current TOB benchmarks, PolePosition's default settings were inherited, except that RDBs other than HSQL and MySQL were excluded, and H2DB was added. It seems PolePosition set VOA JDO on by default, I didn't disable it, but don't know why it didn't appear. JPOX and ObjectDB were not switched on by default in PolePosition, so current TOB benchmarks didn't include them either. But I'm going to include all JDO implementations as possible then rerun the benchmarks again. Further suggestions on this will be appreciated. Especially adhere, I would apperciate feedbacks from TSS editors, if any. What conditions please you tell, under which you will be willing to accept my benchmark results to be published, that I'm going to produce and post as a new article here? Benching source code will be obviously avaiable as it was, to enable everyone run and attach it by themselves.
  44. TOB vs JPOX, and VOA, ObjectDB[ Go to top ]

    I checked out JPOX's latest PolePosition benchmark source, added TOB, and got the result here (I would say at least the 1.1 version from their latest cvs is still far behind TOB in performance) : http://tob.ableverse.org/benchmarks/TOBvsJPOX/ Check it yourselves, or download the source to run your own result. --- VOA seems not opensource anymore, I benched the version shipped with PolePosition 0.2.0, it's near as fast as TOB in the Sepang->read_hot lap. But in other laps, it is rather slower than TOB in reading, querying and updating, and sometimes deletes and writes a little faster than TOB. But an out-dated version is less of interests, and seems I won't be able to publish the latest version's result due to their new license, no more effort paid on it. --- The latest ObjectDB free version just refused to serve that many objects as by PolePosition's default configuration. And since it only allow personal + non-commercial use. I also lost interests on it. --- Any other JDO implementation that could be possiblly compared with TOB?
  45. Download[ Go to top ]

    Hi, where can I find the download link? thanks
  46. Re: Download[ Go to top ]

    http://www.ableverse.com/download-free.jsp http://tob.ableverse.org/benchmarks/src/AV5TOB-Addendum2PolePos0.20.tar.gz http://tob.ableverse.org/benchmarks/polepos020AV5TOBvsJPOX.zip