[sakai2-tcc] Discuss: GenericDAO

[Charles Severance]

I like the idea of these kinds of discussions.  It seems as though the lombok discussion has come together nicely, here is my summary:

It is not likely to be in the kernel any time soon.   It is not likely to be outlawed in a tool or leaf service any time soon.   It is not likely to be forced on tool or service writers.

I would like to start a new discussion about GenericDAO or actually DAOs in general.

We in Sakai could really use a decent ORM-like layer to abstract away portability.  We have a bad mix of GlennDAO, Hibernate, Spring JDBC, and Foorm (yes my little entry into the mix).

Each of these has positives and negatives and it keeps us from standardizing on one.  Here are the plusses and minuses as I see them:

GlennDAO
- Inner Classes
- Obtuse - takes a day just to re-remember how they work
+ Cross-server invalidation for caches
- Caching is obtuse and generates too much DB traffic
- No automatic schema evolution
- Maintenance team size is zero
- Community size is zero unless we are forced to look at the code

Hibernate
+ Portable across DBs
+ Automatic schema evolution
- Sucks at joins (Major)
- Way too much frigging XML
- Massive code bloat
+ Caching is nice 
- Does caching really work cross-server or do we just say three minutes is OK
+ Large community of brainwashed syncophants
+ Lots of active development and bug fixes
- We have no control or input - we are dragged along

Spring JDBC
- Too low level - more like Sakai's DbService
- Solves the easy problems not the hard problems
- No automatic schema evolution
- Uninterested in HSQLDB support
- Impossible to get anything fixed
+ Large community of brainwashed syncophants
+ Lots of active development and bug fixes
- We have no control or input - we are dragged along

GenericDAO
+ Really nice portability across databases
+ Has facility for caching (has this ever been used?)
+ Really really solid query API
+ Loves POJOs
+ Sakai /direct *loves* GenericDAO
- Insists on POJOs - wonder lombok could make this easier ;)
- No automatic schema evolution
- Not in our source tree
- Small development team
- No commits since 2010
- No way to evolve the code to meet our needs

Foorm
+ Nice portability across our three databases
+ Pretty decent schema evolution
+ Does not force POJOs
- Hates POJOs
+ Neat equivalence of models and API patterns between typed and untyped languages - yeah I know - no one cares except for me
+ Has sweet table-driven UI layer that makes CRUD interfaces really quick to build.
+ In our source tree - so we can change it - but no one cares except me
+ Interesting data validation, authz, etc approach
- Lousy documentation - even the creator needs to refresh his memory from time to time as to how something works
- Active development and use by a small community of 1.1 people
- Source evolution is pretty slow although there was a rare bug fix last night 
- Not quite ready for a /direct plug in

So, based on this analysis, I think that the best approach for Sakai as the "ORM of the Future" is an improved GenericDAO.

If we could somehow fork GenericDAO and add a few of the Foorm features like Automatic Schema Evolution, a set of GenericUI annotations to capture the UI bits of the Foorm model, and a way to exchange Properties or Map<String, Object> in addition to POJOs - I think we would have something pretty nice and get all the positives and none of the negatives.

Discuss...

/Chuck