Folks;
in a current situation we are messing with performing a smooth migration
away from a "legacy", pretty much mixed-up database (well, "table"...) and a
proprietary (non-Java) document management system on top of that to (which
is at least what we're aiming for, so far) an application platform mainly
consisting of services utilizing standard Java EE technologies to keep
applications sane, slim and maintaineable (i.e. trying to avoid third party
dependencies).
However, in a given situation and for a given use case, I do have a problem
like this to solve: In part of our database, tables are merely used alike
"Excel spreadsheets" - if in doubt, a new column gets added and eventually
filled with content, making a sane O/R model a difficult thing to have...
However, this is how things work there, and the best way I could come up
with to access this from within Java is to fetch rows of these tables to
Map<String,String> objects, key set being the column names, and values being
the appropriate values in the column for right that cell in the row. I so
far have found several solutions to this:
(a) Use Spring and the SimpleJdbcTemplate helper class. This is what we so
far do in part of our Java integration code, and it works just like that
(returning a table row using something like a "queryForMap" method), of
course at the price of being dependent upon Spring and its dependencies
rather than just using pure Java EE.
(b) Use JPA. This would be our favorite solution for Java EE purposes and
also because JPA is, well, the standard persistence technology that comes
with Glassfish. So far however, I found that doing this kind of work (pretty
"native" SQL operations away from persisting / retrieving defined entities)
is rather difficult; the best I managed to do so far is retrieving a table
row as an Object[] containing the different cells yet omitting the
corresponding column names, thus requiring additional work to get right this
information and ensure the right data ends up in the right place, in the end.
(c) Use plain JDBC. This eventually would allow for doing what I need and
also eventually be the most straightforward solution, of course at the price
of being more low-level.
So, overally, I can't really make up my mind what to do here... stay with
Spring (what we so far use and what, so, "basically is around"), go for JPA,
or use plain JDBC in this part of the application? What do you think?
Cheers & best,
Kristian
--
Kristian Rink
cell : +49 176 2447 2771
business: http://www.planconnect.de
personal: http://pictorial.zimmer428.net
"Past midnight. Never knew such silence.
The earth might be uninhabited..."
//beckett / krapp's last tape//