BeanKeeper

Quick feature list

• Simple to use. Read tutorial and begin to use it in minutes, no special tools required!
• Zero configuration.
• Small footprint.
• Supports PostgreSQL,MySQL,HSQLDB,Oracle.
• Full polymorphism support!
• Simple, readable, easy query language.
• Handles relations expressed with Lists, Maps, Sets, Collections.
• Handles references to other objects, self-references, circular references.
• Lazy loading of objects loads objects only when needed, and only so much what is needed (paging).
• Historical search capability (select objects at a given date).
• "View" selection from multiple objects (scalar query).
• Result list cache.
• Distributed, scalable operation!
• Hierarchical/polymorphic locking (lock classes to lock all instances of that class or any subclass).

Requirements

Ever designed the persistence layer of an "Enterprise" application? The very first question is: What framework to use? EJB, Hibernate or plain JDBC/SQL? Ever thought about basic features this persistence layer must support? Transactions, object locking, safe threading, result list paging, result list immunity to changes inside database, million record result lists, object marshalling/unmarshalling, lists to presentation layer, distributed operations in load-balanced environments. Maybe you have found Your framework, but can you be sure, that for example the result list you get from it is safe outside the transaction? Are you sure that when you save an object, you get it back the same way, with nulls, empty strings, lists, maps, etc? If yes is the answer, how many configuration files do you need to maintain, how many classes are generated, how many classes are "enhanced" runtime? Does it require a separate container to run? Can you maintain it without fancy IDEs or GUI tools?

We found ourselves asking these questions, and found no definite framework which answers all these. The following list is a summary of requirements we were faced with, and on which BeanKeeper was founded:

• No mandatory (XML) configuration please! We found, that configurations (especially an XML-based ones) seriously slow down development, increase maintenance cost and complexity, is a source for errors, and usually contains very redundant information. Ever came across one of these?: ... <id>id</id> <attr name="firstname">first_name</attr> <attr name="age">age</attr> <attr name="birthdate">birthdate</attr> ... BeanKeeper's approach is to use defaults, and if really necessary offer optional settings. Mandatory configuration settings are strictly forbidden. We also consider GUI tools, code generators, etc. workarounds and not actual solutions to this problem.
• Java to Database not the other way around! We, as Java developers want to focus on our model, and don't want to create tables, columns, primary keys, etc. Save my object, and don't bother me with petty questions.
• Recall the object the same way it was (consistence)! If a field was null, then it should stay null on reload. If it was an empty string, it should stay an empty string (...khm.. Oracle.).
• Result list size immunity. We don't care if a result list is 10 items, or 1000000 items, if a select is executed, a List should be returned, with (seemingly) all the items, and the library should do all the optimization it can to enable this. This might include paging, determining the full size, etc.
• Safety! If a list is selected (may be 10 records, but it may by a million) and iterated over, it should be guaranteed that it's safe to do everytime. If the same query is executed again, or the same list iterated again, it should show the exact same result list and object. The result of a query should not ever change inside a transaction, and a specific result List object should definitely not change ever.
• Portability. Usually we develop in a different database environment, than the test/uat/live one, so we want to be sure, that the code will operate the same way in the development Postgres environment, as in the (for example) live Oracle environment. This means, as far as possible, the library should hide all database quirks.
• Scalability. Usually enterprise (web)applications are deployed in a clustered environment, so the library has to support distributed operation, and has to do so, with all guarantees remaining in tact.
• Make fast prototyping possible. This means it should be possible to have one model, so one class hierarchy that can pass from the database layer (from BeanKeeper) right up to presentation without having to be re-packaged in different class hierarchies at the boundaries of each layer/tier. This also means, that objects shouldn't be live copies of database data (ala Hibernate, and others), but should be freely modifiable and only "saved" to database with an explicit "save" call.

With these requirements fulfilled, you truly can concentrate on developing business logic, instead of extending/fixing the persistence layer.