[Building Sakai] Discuss: GenericDAO

Mark J. Norton markjnorton at earthlink.net
Wed Aug 14 06:04:03 PDT 2013


 >  the best approach for Sakai as the "ORM of the Future" is ...

What about the Java Persistence API (JPA)?  This has been getting a lot 
of traction in the wider Java community.

- Mark

On 8/14/2013 8:56 AM, Charles Severance wrote:
> 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
>
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
>
>



More information about the sakai-dev mailing list