Dealing with legacy DBs

[Michael Campbell]

Is there an idiomatic pattern for dealing with legacy databases? I
ask in the context of one of the selling points of lift being "it
handles your schema for you"[1], which is a bit backwards from what
I'm used to. I don't mind changing my thinking, I'm just not sure
where to start that.

Tangentially, is Hibernate the answer?

[1] Or have I misunderstood this point?

[Viktor Klang]

Hi Michael!

 

I've been working with Hibernate in large scale projects now for 4 years, and I have to say that

it is my preferred way of managing Objects <-> RDBMS.

 

I see it as a personal goal to be able to have the possiblility to use /lift/ with any JPA compliant solution,

and I know that there are people using Hibernate with /lift/ already.
 

Does this answer your question?

 

Cheers,

Viktor
 

--
_____________________________________
/                                                                 \
        /lift/ committer (www.liftweb.net )
      SGS member (Scala Group Sweden)
  SEJUG member (Swedish Java User Group)
            Coffee drinker (Skånerost)
\_____________________________________/

[Michael Campbell]

On Dec 18, 2007 9:37 AM, Viktor Klang <viktor...@gmail.com> wrote:
> Hi Michael!
>
> I've been working with Hibernate in large scale projects now for 4 years,
> and I have to say that
> it is my preferred way of managing Objects <-> RDBMS.
>
> I see it as a personal goal to be able to have the possiblility to use
> /lift/ with any JPA compliant solution,
> and I know that there are people using Hibernate with /lift/ already.
>
> Does this answer your question?

Yes and no; "yes" in that if someone is doing it now, it's certainly
possible; "no" in that, I still don't know how to do it myself (with
/lift/). =)

Are there any docs or blog entries or wiki stuff on how this is done?
I think I'm probably too new to Scala and certainly to /lift/ to grok
it all yet, but pointers would be welcome all the same.

If, by going with Hibernate, does that do a complete end-run around
the native /lift/ ORM? Is that necessarily good, or bad? Does it
cause more work elsewhere, say in /lift/s db layer (if such a thing
exists)?

[Viktor Klang]

On 12/18/07, Michael Campbell <michael....@gmail.com> wrote:

DPP is currently de-coupling parts of the Mapper-stuff from /lift/,

which hopefully will lead to a possility to have a plug-n-play Hibernate/JPA configuration in /lift/.

 

There however exist some problems with Hibernate & Scala. (Scala collections have no Hibernate UserCollectionTypes)

 

Cheers,

Viktor

[David Pollak]

There were some rumblings about 6 months ago about some code that
would read your database schema and create lift model objects for
you... nothing has come of that.

As a practical matter, it's not all that hard to do... it's just
work. :-)

If you're already using Hibernate, I'd stick with it.

--
David Pollak
http://blog.lostlake.org

[David Pollak]

The lift OR mapper is an ActiveRecord style OR mapper and it's meant
for small projects. There's nothing in the lift HTML stuff that
relies on the OR mapper or OR mapped classes. There's no end-run if
you use Hibernate. Use it. If there are any issues, I consider them
defects and we'll prioritize fixing them.