You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@cayenne.apache.org by Øyvind Harboe <oy...@zylin.com> on 2007/07/20 20:42:34 UTC

On the fly reengineering of database schema

Currently our Cayenne app has the database field size and types stored
in the configuration files that ship with the application. They were
generated in the Cayenne modeler.

Is there any reason, in principle, why we couldn't read that info
during startup of the application? IOW, reengineering on the fly.

- It would allow database maintainers to adjust field sizes without us
updating Cayenne.
 We have a lot of variants of the database schema in the field and
changing size of a  NVARCHAR or changing an NVARCHAR to a CLOB would
be typical operations.
- Adding a field to a database table could be done from the database GUI
- We would be able to cope easily with the absence or presence of
optional table fields

The Cayenne modeler would still be useful to choose Java
representation of the fields regardless of their type(CLOB, NVARCHAR,
CHAR, etc.).

We have some database adapters that don't do robust reengineering
(FoxBase, MS Access, shudder!), but presumably we could
programatically adapt the Cayenne database schema for those/stick with
a default one which we do today.

-- 
Øyvind Harboe
http://www.zylin.com - eCos ARM & FPGA  developer kit

Re: On the fly reengineering of database schema

Posted by Øyvind Harboe <oy...@zylin.com>.
On 7/20/07, Andrus Adamchik <an...@objectstyle.org> wrote:
> > Is there any reason, in principle, why we couldn't read that info
> > during startup of the application? IOW, reengineering on the fly.
>
> No reason - you can totally do it. Cayenne runtime mapping is
> completely dynamic. It's not like we would need to re-enhance Java
> bytecode or anything :-)

IYO, is it easy/difficult? Good/bad idea for what I'm trying to achieve?

Way to go? Should I look at other alternatives?


>
> Andrus
>
>
> On Jul 20, 2007, at 9:42 PM, Øyvind Harboe wrote:
>
> > Currently our Cayenne app has the database field size and types stored
> > in the configuration files that ship with the application. They were
> > generated in the Cayenne modeler.
> >
> > Is there any reason, in principle, why we couldn't read that info
> > during startup of the application? IOW, reengineering on the fly.
> >
> > - It would allow database maintainers to adjust field sizes without us
> > updating Cayenne.
> > We have a lot of variants of the database schema in the field and
> > changing size of a  NVARCHAR or changing an NVARCHAR to a CLOB would
> > be typical operations.
> > - Adding a field to a database table could be done from the
> > database GUI
> > - We would be able to cope easily with the absence or presence of
> > optional table fields
> >
> > The Cayenne modeler would still be useful to choose Java
> > representation of the fields regardless of their type(CLOB, NVARCHAR,
> > CHAR, etc.).
> >
> > We have some database adapters that don't do robust reengineering
> > (FoxBase, MS Access, shudder!), but presumably we could
> > programatically adapt the Cayenne database schema for those/stick with
> > a default one which we do today.
> >
> > --
> > Øyvind Harboe
> > http://www.zylin.com - eCos ARM & FPGA  developer kit
> >
>
>


-- 
Øyvind Harboe
http://www.zylin.com - eCos ARM & FPGA  developer kit

Re: On the fly reengineering of database schema

Posted by Andrus Adamchik <an...@objectstyle.org>.
> Is there any reason, in principle, why we couldn't read that info
> during startup of the application? IOW, reengineering on the fly.

No reason - you can totally do it. Cayenne runtime mapping is  
completely dynamic. It's not like we would need to re-enhance Java  
bytecode or anything :-)

Andrus


On Jul 20, 2007, at 9:42 PM, Øyvind Harboe wrote:

> Currently our Cayenne app has the database field size and types stored
> in the configuration files that ship with the application. They were
> generated in the Cayenne modeler.
>
> Is there any reason, in principle, why we couldn't read that info
> during startup of the application? IOW, reengineering on the fly.
>
> - It would allow database maintainers to adjust field sizes without us
> updating Cayenne.
> We have a lot of variants of the database schema in the field and
> changing size of a  NVARCHAR or changing an NVARCHAR to a CLOB would
> be typical operations.
> - Adding a field to a database table could be done from the  
> database GUI
> - We would be able to cope easily with the absence or presence of
> optional table fields
>
> The Cayenne modeler would still be useful to choose Java
> representation of the fields regardless of their type(CLOB, NVARCHAR,
> CHAR, etc.).
>
> We have some database adapters that don't do robust reengineering
> (FoxBase, MS Access, shudder!), but presumably we could
> programatically adapt the Cayenne database schema for those/stick with
> a default one which we do today.
>
> -- 
> Øyvind Harboe
> http://www.zylin.com - eCos ARM & FPGA  developer kit
>