Hi Kristian,
Looks you have an interesting project. Hope some one here can help you :-)
Thanks,
Judy
Kristian Rink wrote:
> 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
>