Discussions

News: SimpleORM v3 released - maps objects to databases

  1. We are pleased to announce the release of SimpleORM 3.0, which is a major upgrade and simplification of SimpleORM 2.0. SimpleORM provides a full featured object relational mapping and persistence system in a tiny package that is easy to understand and safe to work with. The entire SimpleORM jars are just 79K and 52K in size, with only one small and optional dependency (Slf4j). (Hibernate is over 2400K plus about 2000K of dependent Jars.) A key technology is to represent objects as essentially a strongly typed map of attributes to their values. One can then define accessors such as public String getPhoneNr() { // Optional get method if you like them return getString(PHONE_NR); } This generalized structure avoids the complex reflection and byte code generation needed to create the pseudo POJOs of other ORMs. The structure also facilitates a clean, string free query language and provides access to extended field state information such as the initial queried value. SimpleORM also packages objects into "DataSets", which enables it to provide well defined semantics for relationships and detached records (unlike other ORMs). SimpleORM also provides transparent access to user extensible meta data. The generalized structure can also enable plug in modules to add fields to an existing record and so provide very flexible application architectures. Keeping it simple and transparent greatly reduces technical risk. If necessary any competent developer can read from the SimpleORM API to the underlying JDBC calls with a very few clicks of the mouse. See http://www.simpleorm.org/sorm/whitepaper.html for details.

    Threaded Messages (36)

  2. Looks good - I like the "don't fear the database" feeling I get from reading the whitepaper. I get that impression with Hibernate; that it is designed by and for people who are too scared to get their hands dirty when it would save a lot of development time and technical risk.

    Of course, I'd only use something like this for accessing legacy databases since I am pretty much exclusively OODBMS (Db4o in fact) on greenfield projects these days.

    Very useful for the integration stuff I have to do though, so thanks! Will definately remember this one for the future.

  3. My idea of Hibernate is that the users want to forget they are forced to use a horrible RDBMS to solve their OO domains. I have personally never seen anyone using Hibernate, or any other ORM tool, to map a legacy db. Most places uses a relational db in lack of better understanding or cowardly hiding behind the "no one has been fired for choosing oracle" mantra. Your are lucky very few of us are fortunate enough to work in project that uses and OO DB.
  4. My idea of Hibernate is that the users want to forget they are forced to use a horrible RDBMS to solve their OO domains.
    I have personally never seen anyone using Hibernate, or any other ORM tool, to map a legacy db. Most places uses a relational db in lack of better understanding or cowardly hiding behind the "no one has been fired for choosing oracle" mantra.

    Your are lucky very few of us are fortunate enough to work in project that uses and OO DB.
    I've used NHibernate and Hibernate with legacy data models in RDBMS. I've also used NHibernate and Hibernate on new projects. The reason RDB is used is because the data is actually relational and an OO approach just isn't an appropriate choice in these situations.
  5. My idea of Hibernate is that the users want to forget they are forced to use a horrible RDBMS to solve their OO domains.
    I have personally never seen anyone using Hibernate, or any other ORM tool, to map a legacy db. Most places uses a relational db in lack of better understanding or cowardly hiding behind the "no one has been fired for choosing oracle" mantra.

    Your are lucky very few of us are fortunate enough to work in project that uses and OO DB.


    I've used NHibernate and Hibernate with legacy data models in RDBMS. I've also used NHibernate and Hibernate on new projects. The reason RDB is used is because the data is actually relational and an OO approach just isn't an appropriate choice in these situations.
    If the data is actually relational, why are you mapping it to objects (I assume with getters and setters)? Doesn't that create at the very least what is commonly referred to as an 'impedance mismatch'?
  6. My idea of Hibernate is that the users want to forget they are forced to use a horrible RDBMS to solve their OO domains.
    I have personally never seen anyone using Hibernate, or any other ORM tool, to map a legacy db. Most places uses a relational db in lack of better understanding or cowardly hiding behind the "no one has been fired for choosing oracle" mantra.

    Your are lucky very few of us are fortunate enough to work in project that uses and OO DB.


    I've used NHibernate and Hibernate with legacy data models in RDBMS. I've also used NHibernate and Hibernate on new projects. The reason RDB is used is because the data is actually relational and an OO approach just isn't an appropriate choice in these situations.


    If the data is actually relational, why are you mapping it to objects (I assume with getters and setters)? Doesn't that create at the very least what is commonly referred to as an 'impedance mismatch'?
    Say I have an address entity and 50 other entities that can have addresses. If I want to avoid duplication of addresses, I "can" use a cross reference table to associate an entity to an address. Of course, I don't "have to" model it relationally and duplicate the addresses. The downside is that if I correct an address, how do I reliably correct all the other addresses? What if there's multiple entries for the same physical address, but some are incorrect, while others are correct? Using a relational model and cross references, I correct the address once and all the associations get that change for free. there's plenty of other reasons, but that is the one that comes to mind. peter
  7. Say I have an address entity and 50 other entities that can have addresses. If I want to avoid duplication of addresses, I "can" use a cross reference table to associate an entity to an address. Of course, I don't "have to" model it relationally and duplicate the addresses. The downside is that if I correct an address, how do I reliably correct all the other addresses? What if there's multiple entries for the same physical address, but some are incorrect, while others are correct? Using a relational model and cross references, I correct the address once and all the associations get that change for free.

    there's plenty of other reasons, but that is the one that comes to mind.

    peter
    I don't understand how this answers the question I asked but aside from that who says an OO design or OO database can't use shared objects?
  8. Hello Guys. Sorry to jump in. Actually, data is not relational or OO per se. The way you model your solution or the data processing needs are. Say, if you want to work with some instances modeled by entities with behavior, you need OO. If you need Entities to be massive and filtered in a quick way, you may go for relational. The difference is simple: I would use relational to store massive detailed data organized as attribute sets. Normalization is to reduce size and updates, but not good for queries. I would then process that detailed data into business info, and that info I can model it in Objects. For instance, I don't see myself requesting all filtered records in a query into an object array, to just count the array items later. I would load an object from a record (or two or three but not much more) to resolve a specific operation. But massive processing, that should go to relational or hierarchical (ask American Airlines). To me ORM always causes impedance mismatch. The question is how much do you need it and how much does it cost.
    William Martinez Pomares.
    Architect's Thoughts
  9. OO DB myth[ Go to top ]

    there we have it again - the ever recurring myth of the OO DB that will make things easy and self-evident for everyone. This idea has been around since the early days of OO programming (at least the early 90ies of the last century of the previous millenium). The problem with the idea of OO DBs, however, is that contrary to the relational model it is not based on sound and complete theory. The outcome of this is that every one of the attempts to create enterprise-ready OO DB products has failed miserably (counter examples anyone?). Among other things, the availability of a full-featured query language (SQL) was something these products were never able to match. IMO the relational model is as OO as data ever gets.
  10. Re: OO DB myth[ Go to top ]

    there we have it again - the ever recurring myth of the OO DB that will make things easy and self-evident for everyone. This idea has been around since the early days of OO programming (at least the early 90ies of the last century of the previous millenium). The problem with the idea of OO DBs, however, is that contrary to the relational model it is not based on sound and complete theory. The outcome of this is that every one of the attempts to create enterprise-ready OO DB products has failed miserably (counter examples anyone?).

    Among other things, the availability of a full-featured query language (SQL) was something these products were never able to match.

    IMO the relational model is as OO as data ever gets.
    Objectivity is an enterprise ready object database. The relational database myth is that today's SQL databases are an implementation of relational theory. The gaps between SQL databases and the relational model are not simple lapses in discipline, or small disagreements about whether a relation needs a primary key. They are significant failures to deliver the core benefits, in addition to invalidation of any supposed soundness. For example the model requires that decisions regarding the positioning of information are purely for performance purposes, but today's enterprise SQL databases can't position data in one relation with data from another relation.
  11. Myth -s- Reality[ Go to top ]

    there we have it again - the ever recurring myth of the OO DB that will make things easy and self-evident for everyone. This idea has been around since the early days of OO programming (at least the early 90ies of the last century of the previous millenium)..
    Well, nothing in data management is easy, but then everything is relative. Relative to dealing with the overhead in mapping your language memory constructs to relational storage constructs .... definitely easier with an OODB. Besides, what's your point, the ideas behind distributed computing have been around since the 1940's and only today as a clear need arises do you see that paradigm manifesting in every day implementations. The fact that an idea is old does not provide any indication of it' merit .... There is an ever increasing need for OODB type constructs in todays increasingly complex software implementations.
    The problem with the idea of OO DBs, however, is that contrary to the relational model it is not based on sound and complete theory. The outcome of this is that every one of the attempts to create enterprise-ready OO DB products has failed miserably (counter examples anyone?). .
    First, not a single RDB on the market fully implements E.F. Codd's relational theory. Second show me a significant application that uses a relational database an I'll show you a system that is breaking all the relational rules because it's the only way to get perfomance. Third, show me the mathmatical theory behind all the software that doesn't use a database: are you saying they should not work because they don't have a mathmatical foundation... algorithms work, use them wisely. An increasing number of significant RDB backed applications on this planet are using relational technology as a file based concurrency control processer, not as a proper relational storage engine. Just some quick ones everyone knows: eBay, Yahoo, Amazon, LiveJournal, FaceBook, etc manage most relationships in the application space because the concurrency, amount of data, and model complexity doesn't allow them to do it inside the relational database. These companies have in essense built their own OODB's with limited but specific capabilities. Now as far as successful commercial OODB's. How about Versant. It's a public company generating millions in profit every year and running some of the most complex, high performance, low latency appliations in the world. For example, Sabre Availability Processor... you know the GDS ( Global Distribution System ) that feeds Travelocity, All Major Airlines, feeding Expedia, Hotwire, Hotels.com and many more .... you know that original application that caused IBM to create the mainframe ... yeah that run's on Versant.
    Among other things, the availability of a full-featured query language (SQL) was something in the database. these products were never able to match
    Wrong again: Versant has always had a server side, indexable, query execution engine. It's OQL and looks surprisingly like SQL with similar features. This is just miss information spread by the fact that a few of the early OODB's did not have query. The real issue was that tool vendors did not support OQL, so in the early days you could not run out and use Crystal Reports and point it at an OODB. Those issues are long since past with most OODB vendors providing odbc/jdbc bridges and supporting other Java query standards. "seeking truth in disclosure" Robert Greene Versant Corporation
  12. Re: Myth -s- Reality[ Go to top ]

    Relative to dealing with the overhead in mapping your language memory constructs to relational storage constructs .... definitely easier with an OODB.
    not much of a problem IMO with a good mapper.
    Besides, what's your point, the ideas behind distributed computing have been around since the 1940's and only today as a clear need arises do you see that paradigm manifesting in every day implementations.
    my point is that even though the "idea" of OODBs has been around for so long, none of the implementations has had real success. And I dont see that changing, because besides the fact that it is really hard to replace a core system like a DBMS, I dont see much benefit in doing so either (at least as long as we are talking of mainstream business computing). Of course there are niche areas where OODBMSs shine..
    First, not a single RDB on the market fully implements E.F. Codd's relational theory.
    So what? As much as is correctly implemented yields its benefits many times over.
    Second show me a significant application that uses a relational database an I'll show you a system that is breaking all the relational rules because it's the only way to get perfomance.
    hm, I better not answer that claim directly. I'll rather leave it at a "not my experience at all". Most "significant applications" I have seen at least keep the first 2 normal forms..
    Third, show me the mathmatical theory behind all the software that doesn't use a database: are you saying they should not work because they don't have a mathmatical foundation...
    no, I didnt say that - what makes you think I did? I do think that a database, being a long-lived resource that is accessed in various and even interactive ways, benefits from a sound and transparent model more than other software.
    Wrong again: Versant has always had a server side, indexable, query execution engine. It's OQL and looks surprisingly like SQL with similar features. This is just miss information spread by the fact that a few of the early OODB's did not have query. The real issue was that tool vendors did not support OQL, so in the early days you could not run out and use Crystal Reports and point it at an OODB. Those issues are long since past with most OODB vendors providing odbc/jdbc bridges and supporting other Java query standards.
    now thats funny. After having bashed the RDMSs you point out that Versant has a relational or relational-like query interface. Maybe there is some good in relational after all.. regards, Christian
  13. Re: Myth -s- Reality[ Go to top ]

    now thats funny. After having bashed the RDMSs you point out that Versant has a relational or relational-like query interface. Maybe there is some good in relational after all..
    Hmm... I don't see where I bashed relational databases at all in that post ... though I admit, I did it a bit in another ;-) I subscribe to the school of - right tool for the job. RDB's are clearly an excellent tool. BTW - successful commercial products that use an OODB, an example of right tool for the job - How about Oracle's supply chain management (SCM)? Yeah, they use the Versant OODB in that solution. "seeking truth in disclosure" Robert Greene Versant
  14. Say I have an address entity and 50 other entities that can have addresses. If I want to avoid duplication of addresses, I "can" use a cross reference table to associate an entity to an address. Of course, I don't "have to" model it relationally and duplicate the addresses. The downside is that if I correct an address, how do I reliably correct all the other addresses? What if there's multiple entries for the same physical address, but some are incorrect, while others are correct? Using a relational model and cross references, I correct the address once and all the associations get that change for free.

    there's plenty of other reasons, but that is the one that comes to mind.

    peter


    I don't understand how this answers the question I asked but aside from that who says an OO design or OO database can't use shared objects?
    sorry I forgot to answer your original question. the reason for mapping the relational data to object is so other applications can reason over the data and display it. Depending on the application the same data may have 1 or more views. There may also be business rules that reason over the data using a variety of views of the same underlying relational data. you're totally right a OODBMS could store references of the same object, rather than making copies. In the past, I've used XStream to write object graphs to a file, where the same object instance is referenced by multiple objects. What I like about using a relational model is that I can create a materialized view of several entities and map a summary object to it. One could argue you can do the same thing with an OODBMS, but I haven't seen that done myself. Are there any OODBMS that provides that kind of functionality? peter
  15. Materialized View in an Object Database[ Go to top ]

    What I like about using a relational model is that I can create a materialized view of several entities and map a summary object to it. One could argue you can do the same thing with an OODBMS, but I haven't seen that done myself. Are there any OODBMS that provides that kind of functionality? peter
    In the SQL world, a materialized view is a collection defined declaratively in SQL that is efficiently kept up to date when any of the underlying components are updated. There are many approaches to this kind of thing in the OO world, and how you feel about them probably depends on how you feel about a declarative as opposed to a procedural definition of a collection. One I think is interesting is ActiveQuery in the Tangosol API where clients not only get a static view, but they also get events to keep a live view of the data up to date.
  16. Re: Materialized View in an Object Database[ Go to top ]

    What I like about using a relational model is that I can create a materialized view of several entities and map a summary object to it. One could argue you can do the same thing with an OODBMS, but I haven't seen that done myself. Are there any OODBMS that provides that kind of functionality?
    peter


    In the SQL world, a materialized view is a collection defined declaratively in SQL that is efficiently kept up to date when any of the underlying components are updated.

    There are many approaches to this kind of thing in the OO world, and how you feel about them probably depends on how you feel about a declarative as opposed to a procedural definition of a collection.

    One I think is interesting is ActiveQuery in the Tangosol API where clients not only get a static view, but they also get events to keep a live view of the data up to date.
    Right, you could do the equivalent of a data transformation object, which does something similar to a materialized view. I'm not aware of any OODBMS that provides that functionality. If anyone knows of one that does, I'd be curious to hear about it. The other benefit that I like about ORM is that I have the possibility of mapping an object to an MDX query to slice and dice the data for reports. One could use materialized views to create summary tables, which are OLAP-Like but don't necessarily have the same performance benefits. peter
  17. sorry I forgot to answer your original question. the reason for mapping the relational data to object is so other applications can reason over the data and display it. Depending on the application the same data may have 1 or more views. There may also be business rules that reason over the data using a variety of views of the same underlying relational data.
    In my current work, data is king. The code is subservient to the data. This isn't how things were in my previous work where data was just means to an end. When the data is the most important thing, I have trouble seeing how OODBMS will work. For one thing, OO programs are only one type of client to the data. My second thing is that it seems to me that there is a tendency in Java-land to map everything from the db to POJO objects. I think this makes a lot of sense for most CRUD w/ logic apps but for most of my db oriented work, it's going to kill our productivity. The depth and breadth of the data is too great. We have to deal with things at a higher abstraction level. That's really where my initial question was going.
  18. sorry I forgot to answer your original question. the reason for mapping the relational data to object is so other applications can reason over the data and display it. Depending on the application the same data may have 1 or more views. There may also be business rules that reason over the data using a variety of views of the same underlying relational data.


    In my current work, data is king. The code is subservient to the data. This isn't how things were in my previous work where data was just means to an end.

    When the data is the most important thing, I have trouble seeing how OODBMS will work. For one thing, OO programs are only one type of client to the data.

    My second thing is that it seems to me that there is a tendency in Java-land to map everything from the db to POJO objects. I think this makes a lot of sense for most CRUD w/ logic apps but for most of my db oriented work, it's going to kill our productivity. The depth and breadth of the data is too great. We have to deal with things at a higher abstraction level. That's really where my initial question was going.
    right, I see where you're going. In my case, many types of applications consume the data, so there's many representations of the same data. One application looks at it through 1 object model, and other applications view it through another object model. There is potentially an impedance mis-match, but I don't think that problem will ever go away. in some cases, we used MDD to model the objects at a higher level and code gen all the artifacts. in other cases, we model the objects in a commercial tool and hand code the objects. then there's issues like auditing and data archiving. In many of the projects I've been on, we had to archive old data into an archive table, so using an ORM allows me to map a single object to multiple tables. This is beneficial to me because the same UI can display current data and archived data. there's other ways of achieving the same functionality. peter
  19. right, I see where you're going. In my case, many types of applications consume the data, so there's many representations of the same data. One application looks at it through 1 object model, and other applications view it through another object model. There is potentially an impedance mis-match, but I don't think that problem will ever go away.

    in some cases, we used MDD to model the objects at a higher level and code gen all the artifacts. in other cases, we model the objects in a commercial tool and hand code the objects. then there's issues like auditing and data archiving. In many of the projects I've been on, we had to archive old data into an archive table, so using an ORM allows me to map a single object to multiple tables. This is beneficial to me because the same UI can display current data and archived data.

    there's other ways of achieving the same functionality.
    I've used code generation in the past both through commercial tools and my own hand-rolled generators (interestingly I've had much better results with my own generators). The thing for me is that out of hundreds of fields, I'm generally only explicitly using a handful for logic. The rest are just along for the ride and tend to be somewhat transient. In some cases I have no field specific logic to implement at all. For example, I was able to implement a program that will populate tables from messages such that new archive tables and corresponding messages can be added without touching my code or even restarting the JVM. If we had gone with the standard hibernate (or equivalent) approach, that would not be possible. I could achieve the same sort of results using reflection but why generate statically-typed code merely to execute dynamic operations against it? It requires a costly and risky extra step that provides no value. I just get the idea sometimes that this is considered an unorthodox and crazy approach by a lot of developers and designers. Maybe I'm just imagining it.
  20. I could achieve the same sort of results using reflection but why generate statically-typed code merely to execute dynamic operations against it? It requires a costly and risky extra step that provides no value.
    Amen! I think this is an extremely important point that a lot of people are either missing or ignoring. The IDEs and analysis tools are much further ahead for proper static typesafe code. You will win back any time lost to the initial extra effort by the time the product is debugged and delivered to the customer. You'll win back even more time when a maintenance team takes over supporting the product and they can actually step through with a debugger, search for problems with the latest version of findbugs, and see a complete and accurate call graph with the touch of a button. Whether the ORM code is generated or handwritten is a separate issue of less importance as long as the IDEs are able to help. -Jonathan
  21. Object Oriented vs Relational[ Go to top ]

    To my mind, Object Oriented vs Relational is not what an ORM is about, despite the name. The key issue is that we need to relate data in memory with data in the database, and keep it synchronized. We need careful managment object identity, life cycle etc. At a practical level, the difference between C++/Java etc. objects and relational is that the former do not understand relationships. When one sets an Fred's Department to be Sales in a relational database the index is automatically updated, so that the Sales department must contain Fred. But in object oriented C++/Java one must synchronize them manually. And they can be made inconsistent, eg. fred.department = sales; engineering.employees.add(fred); Hibernate has real problems with this type of construct because it tries to apply the low level object approach to the high level relational approach. SQL 1999 actually does enable one to create a new ADDRESS type (say) with columns FirstLine, SecondLine etc. and then use that in a table definition. It can even be directly embedded, or accessed by reference. Just like C++ (not Java). Oracle at least has supported this for a long time. Fortunately these features are rarely used. No ORM supports them AFAIK, and most report writers will choke on them. If you have 50 tables with Address fields then you need to redesign your schema. But if you have 2 or 3, then you can easily separate the definition of the address fields in SimpleORM -- see the white paper. Anthony
  22. The reason RDB is used is because the data is actually relational and an OO approach just isn't an appropriate choice in these situations.
    Could you describe a data that is "relational" and not OO. As I see it the only difference between a relational db and a OO db is that is the OO db you define the relations upfront and in a relational database the relations are defined at query time.
  23. I found a better and powerful ORM, but it is only in japanese (docs, ecc.). Check out here: http://74.125.93.104/translate_c?hl=it&langpair=ja|en&u=http://s2dao.seasar.org/ja/&usg=ALkJrhhAsAB7bzcjDcPrdpF-vnmDJc20iw
  24. I am not familiar with 'SEASAR s2Dao' the open-source ORM framework referenced by this posting, but I did figure out the following URL that provides English, Japanese and Chinese documentation links: http://s2dao.seasar.org/en/index.html Again, this is not an endorsement of the 'SEASAR s2Dao' open source framework. I do not necessarily agree with the original posters claim that s2Dao is 'better' than SimpleORM.
  25. Where download the product directly?
  26. Re: SimpleORM[ Go to top ]

    I really like it, specially: - tiny (Hibernate is too big sometimes) - no XML - no annotations - no configuration - the fluid query API - no byte code processing, debuggable What I don't like is: - the 'S' (SRecordMeta, SFieldString,...) - I don't want to register for a download - the web site could look better I am writing something similar, currently distributed as part of the H2 database engine: JaQu (Java Query).
  27. SimpleOrm vs H2 JaQu[ Go to top ]

    I like JaQu's simple syntax. But JaQu stores values in POJOs. If you try to enhance this you will quickly end up with the same problems that led Hibernate to the byte coded pseudo POJO mess. ORMs are tricky to get right, as are databases. When H2 gets locking it will be very interesting. One thought is that between crude read locks and full and complex MVCC locks one can have db implemented optimistic locks. Whenever a record is read, it is weakly locked. If another transaction updates the record the lock is silently broken. But if the first transaction then tries to update the record you throw an exception (otherwise exclusively lock). This is a good and safe solution in practice for short transaction web like applications. Incedentally, if anyone is unaware of how MVCC locks can corrupt a database then I strongly recommend you read the section in the Locking section in the SimpleORM Whitepaper. Anthony
  28. Re: Simpleorm[ Go to top ]

    Hi, the web site is not very pretty, but the product is really cool. Regarding the need to register... well, actually you don't need to, just check it out from: https://simpleorm.svn.sourceforge.net/svnroot/simpleorm/trunk But I agree with you this download form is counter productive...
  29. Simply put: how does it compares to iBatis ? ZC.
  30. SimpleORM vs iBatis[ Go to top ]

    SimpleORM is almost the antithesis of iBatis. SimpleORM uses no XML and supports object identity, so can automatically update. iBatis's goal is mainly just to move SQL Queries out of the java code and into XML. I personally do not see any value in that. If you want to use an ORM I suggest you lift the rawQuery/Update methods out SimpleOrms SSessionJdbc.java and keep it simple. Anthony
  31. Wow! SimpleORM is simply great! It's a pleasant surprise to see ORM covered in such depth, not only in breadth (as in Hibernate). SimpleORM's approach goes well together with code generation (using SimpleORMGenerate or another tool). There's only one drawback I currently see: SQL is not directly supported, only raw Predicates "that do not produce normal objects". In some environments it's necessary for several reasons to provide 'visible' SQL statements.
  32. Raw SQL support[ Go to top ]

    For simple queries we avoid raw SQL, but it will always be required for complex, database dependent queries. SimpleORM supports Raw SQL in two ways. Firstly one can simply add a SQL fragment to normal SQueries as follows. SQuery rawJoinQ = new SQuery(Employee.EMPLOYEE) .rawJoin("LEFT OUTER JOIN XX_DEPARTMENT D ON D.DEPT_ID = XX_EMPLOYEE.DEPT_ID") .rawPredicate("D.DNAME = 'F100'"); Alternatively SimpleORM provides a convenient wrapper for performing arbitrary SQL queries List Sals = ses.rawQueryMaps( "SELECT E.DEPT_ID, SUM(E.SALARY) as \"SUMSAL\" FROM XX_EMPLOYEE E " + " WHERE E.DEPT_ID IS NOT NULL" + " GROUP BY E.DEPT_ID ORDER BY E.DEPT_ID", true); (Each map represents one row of the result. These methods are short and self contained and could be picked out of the SimpleOrm code for those that do not want to use any ORM.) It should be noted that these are both for completeness. The vast majority of queries in practice just use the clean SQuery syntax. These are covered in the white paper. Anthony
  33. Revival of an old nice idea[ Go to top ]

    Back then in the old times with Smalltalk and C++ where there wasn't any Java yet we did it that way already: storing attributes in a map with getter and setter methods that hide the use of a map. Then came java with reflection and AOP. Solutions by design were not hip any more. Earlier when using Smalltalk you had to show that there was no way to solve the problem without a perform (what is called reflection in Java). Nowadays you have to make use of reflection at least, better of AOP in addition to solve a problem that can be solved without all that stuff. Otherwise some little kiddies tell you that you are a total ignorant technology agnostic. Good to see that these people at SimpleORM had the guts to look for ways without reflection et.al. Cheers, Oliver
  34. The best Simple ORM I've used[ Go to top ]

    Persist http://code.google.com/p/persist/ No brainer auto mapping of fields and tables. Truly is an OR"M" and doesn't contain YAQL. It uses straight SQL with simple parametrized queries. It's in its early stages but it's highly under appreciated.
  35. Another really Simple ORM[ Go to top ]

    this ORM is simple and elegant http://ammentos.biobytes.it/
  36. In response to comments it should be noted that although simply implemented, SimpleORM is a full featured ORM and not just a database row reader/writer. Queries can be specified safely in terms of Java objects, object identity is aligned with database keys, relationships between objects are maintained and modified objects are automatically flushed to the database with optimistic locks. Optimistic locks are critical for the integrity of multi user web applications. And object identity is important in larger systems to prevent independent business rules from overriding each other's data. SimpleORM functionality is therefor much closer to Hibernate and entity beans than basic tools such as iBatis, DdlUtils, Butler, JaQu, Persist, Ammentos etc.
  37. Congratulations on the release Anthony! Working with relational databases is such a pain in the butt, always good to see more tools to help developers forced to use this technology even when it's inappropriate. "seeking truth in disclosure" Robert Greene Versant