[Building Sakai] Discuss: GenericDAO

[Aaron Zeckoski]

Just a couple minor corrections on the GenDAO stuff:

- Insists on POJOs - wonder lombok could make this easier ;)

That's not quite right. It will happily work with public fields (and
could work with non-public ones but I limited it to publicly visible
stuff since it seemed wrong to introspect into private class fields).
In fact, this is 90% of the time how I use it.
The only tricky thing here is that if you use it with hibernate
underneath then hibernate is not as friendly and does require getters
and setters. If you use it with spring JDBC underneath then it doesn't
matter so it is really hibernate that brings the requirement.


- No automatic schema evolution

Again, if used with hibernate it just does what hibernate does. When
used with spring you will have to manage this yourself but it will
give you place to hook in "make changes on startup as needed".


Also, for hibernate:
With the newer version in trunk we could be using annotations HOWEVER
that probably means upgrading the existing stuff since the XML and
annotation configs don't always work so well together. We would
probably just have to try it and see how well it plays.

That said, I generally dislike hibernate because even though it saves
time up front I inevitably run into complex issues with the way it
handles things and often there is simply no workaround at all except
to not use hibernate and establish a separate JDBC connection. Those
kinds of issues burn days of time and are very difficult to solve. The
magic in those cases is simply not worth the savings in writing the
SQL in the first place and I have spent far too many late nights of
trying to figure out why hibernate would not work for case X.

-AZ


On Wed, Aug 14, 2013 at 5:56 AM, Charles Severance <csev at umich.edu> 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"



-- 
Aaron Zeckoski - Software Architect - http://tinyurl.com/azprofile