Kristian,
Why is depending on Spring such a big problem? Only because it's not "pure JEE"?
Have you considered using Ibatis? It's not real JPA, but not plain JDBC either.
HTH, Wouter
On Wed, Mar 18, 2009 at 09:51:29PM +0100, 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
>
> --
> 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//
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: quality-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: quality-help_at_glassfish.dev.java.net
>
--
People: "If she weighs the same as a Duck, she's made of wood!"
Sir Bedevere: "And therefore...?"
[Monty Python and the Holy Grail]