> Not sure what your use case is here:
>
> 1) A single mapped object can exist in different dbs?
> 2) Different mapped objects can exists in different dbs?
>
> With the current design, 1) is not possible. Once the name of a field
> has been determined, it'll stay fixed.
>
> 2) Might be doable if we add the connection identifier as parameter to the 
> function
> that decides the names.
>
> In general, I don't think we should be too smart about this. There will
> probably always be scenarios that can fail, in which case you can
> manually override the name (except in 1) above :-)

My use case is really #2.  Imagine a Lift App that connects to a
Sybase database and an Oracle database.  I have Mapped objects for
each.  The Sybase objects should use camelCase, while the Oracle
objects should use snake_case.

My other goal is to be agnostic at the code level.  I want to be able
to create an application that could be deployed on several database
platforms.  (Like I can theoretically do with Hibernate.)  So, I want
to be able to define a Mapped class as straight forward as possible
(i.e. declare my primary key id (idPK trait), and the various fields,
etc.)  I don't want to make choices in the Mapped object that depend
on the underlying database platform.  Overriding the column name is
one of those choices; by overriding the dbColumName = 'widgetsHit', I
am making the camelCase/snake_case decision.

I'm not sure that I foresee use case #1...  (I'm not sure that is even
something that I could do in Hibernate.  I certainly have never needed
that functionality.)

FWIW...  JPA is not without its issues.  I don't like the fact that
the @Column annotation has a columnDefinition that is one value.
Certainly, you want to use it sparingly, but once you define it, you
have made your code database platform specific.  You can't say at this
level, "for Sybase or SQL Server, the type is 'bit' and for Oracle,
the type is 'number(1)'."  I know there are ways around this -- you
need to come up with different orm.xml's for each database
platform...  But somehow, the spec breaks down for me.

-- 
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

Reply via email to