It might be worth noting that Ebean uses not null constraints to determine the type of join (inner/outer) to use for relationships. Ebean 1.3 will instead use @NotNull as well as @Column(nullable=..) to replace the DB meta data checking currently done.

FYI:

The DDL generation and refactoring required to remove the DB meta data has been done and is in HEAD.

Looking at the internals of configuration... with an eye to refactor that and expose more for programmatic initialisation - typically for Spring (aka building EbeanServer programmatically).

FYI:

@CreatedTimestamp and @UpdatedTimestamp
========================================
At this stage I'm thinking of requiring explicit use of annotations @CreatedTimestamp and @UpdatedTimestamp. This would replace the naming convention approach used at the moment.

The thinking here is that with the removal of the Insert/Update/Delete functionality from MapBean's it is better to make this explicit via annotations.

Note: on the TODO list is add support for @CreatedUser and @UpdatedUser.

Configuration
===============
The way Ebean is configured is being refactored...

It is likely to be broken up into several config objects

- ServerConfiguration ....
- AutofetchConfig .... Autofetch/Profiling options
- DataSourceConfig .... JNDI or url/driver etc or DataSource object
- DatabasePlatform .... for config specific to the Database type (Oracle, H2 etc)
- NamingConvention .... for property/column (Underscore/Matching etc)

This should be much better for programmatic configuration (Spring configuration etc) and better documented.

NOTES:
-------------------
- ServerConfiguration has changed a lot and re-packaged
- NamingConvention has been made simpler (moved sequence stuff to DB specific configuration)
- DatabasePlatform and related objects exposed as part of configuration (You won't explicitly need to configure this as it can be determined from the DataSource automatically but I think it is good to expose this as public API).

EbeanServerFactory
===================
I'm introducing a EbeanServerFactory object that replaces the Ebean.register() method which has been removed. The thinking behind this is to make it clearer that:

- You can create/use EbeanServers without using the Ebean(singleton) at all. In v1.3 you can create an EbeanServer via EbeanServerFactory and not register it with the Ebean(singleton).

- Ebean(singleton) is:
1) a Map of "registered" EbeanServers
2) A convieniance API to use the "primary/default" EbeanServer

Thanks for the good work, Rob.

I'm one happy user.

p.s. I need to login twice into this blog to make it happen (?).

>> Good work
You're welcome. Quite a few nice improvements in this version I reckon :)

>> login twice
Yeah. A strange problem with Https on my server. Been meaning to investigate/fix it ...

FYI:

The next release is going to be v2.0 (not 1.3). It is a version that has a lot of significant changes (DDL Generation, ServerConfig refactoring etc).

It is mostly done but needs tidy up work and the documentation needs updating so its still realistically a couple of weeks away.

Cheers, Rob.