FAQ
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

Search Discussions

  • Andrus Adamchik at Jul 20, 2007 at 6:51 pm

    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
  • Øyvind Harboe at Jul 20, 2007 at 7:03 pm

    On 7/20/07, Andrus Adamchik 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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupuser @
categoriescayenne
postedJul 20, '07 at 6:42p
activeJul 20, '07 at 7:03p
posts3
users2
websitecayenne.apache.org

2 users in discussion

Øyvind Harboe: 2 posts Andrus Adamchik: 1 post

People

Translate

site design / logo © 2022 Grokbase