BeanKeeper project was formerly called "Simple Persistence for Java" and is a full featured, powerful object/relational persistence and query library for Java.
Java enterprise software, and according to some, the Java language itself tends to go in the direction of extreme softcoding, or at least, in the direction of additional complexity. We've seen it happen with the EJB framework, and more recently, the Java Server Faces.
That does not need to be so! Other Java persistence frameworks such as Hibernate, TopLink or pBeans already are catching up to the philosophy of simpleness over "abstractness", however, we think there are more steps that can be taken in this direction.
From a developers point of view, especially in a high-level language such as Java, it is a sane assumption, that I do not have to (do not want to) get into the gory details of storing an object, I do not want to hold the database's hand on how to store my object, I do not want to tell it how to create approriate tables, columns, indexes, how to join tables, how to manage connections, how to allocate disk space, how to optimize queries, etc. I assume a "database" as such, should know how to do that without my help, that's why it's called "database".
So the point is, a good library should not get in the programmer's way, but adapt to the usage of the programmer, and adapt to patterns commonly used. This is what BeanKeeper tries to do. You don't need to (and you can't even) tell it how to store objects, it simply does. You don't need to specify the schema, relation model, id/key attributes, fetching algorithms, database dialect, or anything like that, you can focus on writing the business logic.
So how does all this philosophy stuff translate to a persistence software library? The library is not only supposed to handle all low-level database operations transparently, but also some of the more high-level functions. This must be done in order to enable the developer to concentrate only on writing logic.
Here are some key features of "BeanKeeper":
· Simple usage, which is possible with learning only 3 methods, and reading the tutorial.
· Zero-configuration. Nothing needs to be configured, only the database url is needed for the library to initialize.
· Scalability. The library is capable of distributed operation, from virtually unlimited nodes.
· Relations like references to other objects, Lists, Maps, Sets, Collections are handled 100% transparently by the library.
· Large result sets are automatically paged! Paging is 100% transparent, so a million-record result list can be given directly to the presentation layer, without caring for memory usage and database load!
· Transactions are always 'serializable'. Meaning: during a transaction nothing can influence the result of queries from outside the transaction. This practically means, a programmer does not have to care about other transactions possibly influencing the logic inside his transaction.
· Full (transparent) polymorphism support ensures that (most of the time) the library does not get in the way of the programmer. The model is persisted just in the way the programmer expressed through inheritence, and is recalled with all the attributes of polymorphism.
· A custom, object oriented query language ensures, that no complicated SQL needs to be written.
· Scalar query support enables view-centric, more efficient data recall.
· Real portability between databases. BeanKeeper hides all database specific behaviour from the programmer, like: null value handling, empty strings (oracle), case sensitive and insensitive searches, reserved names, etc. That means, one can switch between database implementations, and can assume that (with the exception of a few documented cases) the software build upon the library will continue to work.
What's New in This Release: [ read full changelog ]
· 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).