OpenJPA
  1. OpenJPA
  2. OPENJPA-1850

Dynamic runtime @Table name configuration

    Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: usability
    • Labels:
      None
    • Environment:
      All environments

      Description

      I'm wondering if there is a way to map multiple tables who's name won't be known until runtime to a single entity class. More specifically, My application uses a single entity which it knows the schema for, but not the table name until runtime. The applications has to read the table name from another know table after startup. All there is at deployment is the key into that table. The application consists of a farm of identical apps all running different configurations. They basically store data from different JMS queues to the database.

      I can't find anything useful about this except some byte code manipulators which don't seem to work on the annotation since it appears that the class is already loaded.

      I think there is a legitimate need for such an enhancement. I often have run into sqlServer users who don't know how to use segmented clustered indexing or can't install an Enterprise version so don't have access to this. They create multiple tables and use prepared statements.
      This would enable other cheap dbms to be used without having to worry about locking and contention at the table level.

      Does anyone have any opinions on this?

        Activity

        Hugh created issue -
        Hide
        Michael Dick added a comment -

        If you have a known list of table names this could be done by having a separate orm.xml file for each table. The orm.xml file could be provided at EMF instantiation time (not sure if we have this capability right now - if not it should be doable).

        Failing that I suspect one could manipulate the meta data prior to the entity type being instantiated (this usually triggers the first 'hit' to our internal repository). We'd want a defined interface that takes some of the rough edges off.

        So I guess my question is whether we're selecting from a known group of tables, or whether it would need to be fully dynamic? Either way it sounds like it could be useful, if slightly dangerous.

        Show
        Michael Dick added a comment - If you have a known list of table names this could be done by having a separate orm.xml file for each table. The orm.xml file could be provided at EMF instantiation time (not sure if we have this capability right now - if not it should be doable). Failing that I suspect one could manipulate the meta data prior to the entity type being instantiated (this usually triggers the first 'hit' to our internal repository). We'd want a defined interface that takes some of the rough edges off. So I guess my question is whether we're selecting from a known group of tables, or whether it would need to be fully dynamic? Either way it sounds like it could be useful, if slightly dangerous.
        Hide
        Hugh added a comment -

        The group of tables are not known at compile time. The specific table isn't known until runtime. I'd like to be able to add new tables at anytime and run a new instance of this application to service it.
        It's name is read from a table in another database or from the properties file.

        I agree it is slightly dangerous if the wrong table name is used, but at most it will throw an error because the structure is different.

        I have a byte code manipulator that I use to rewrite the @Table name annotation, but it never gets asked to load my class. I see every other class being loaded.
        The sql trace shows an error when the dummy table name is used.
        I'm using Thread.currentThread().setContextClassLoader(New TableClassLoader(Thread.currentThread().getContextClassLoader()));
        This is run in theMain class and I see the class I'm interested in being constructed after this.

        How can I get my ClassLoader to be used to load this class?

        I have a fully worked example I'll upload but it depends on the ASM bytecode manipulator and jtds.

        Show
        Hugh added a comment - The group of tables are not known at compile time. The specific table isn't known until runtime. I'd like to be able to add new tables at anytime and run a new instance of this application to service it. It's name is read from a table in another database or from the properties file. I agree it is slightly dangerous if the wrong table name is used, but at most it will throw an error because the structure is different. I have a byte code manipulator that I use to rewrite the @Table name annotation, but it never gets asked to load my class. I see every other class being loaded. The sql trace shows an error when the dummy table name is used. I'm using Thread.currentThread().setContextClassLoader(New TableClassLoader(Thread.currentThread().getContextClassLoader())); This is run in theMain class and I see the class I'm interested in being constructed after this. How can I get my ClassLoader to be used to load this class? I have a fully worked example I'll upload but it depends on the ASM bytecode manipulator and jtds.
        Hugh made changes -
        Field Original Value New Value
        Attachment turret.zip [ 12457815 ]
        Hide
        Jeremy Bauer added a comment -

        Another thought would be to provide a variable syntax for annotation values. For example: @Table(name="$

        {TBL_NAME}

        "). OpenJPA could do runtime variable replacement while processing metadata and/or mapping information using system variables or some other means. This leads to the issue of finding a variable syntax that isn't a valid table name on some platform. But, a configuration setting could be used to enable/disable the feature altogether.

        Show
        Jeremy Bauer added a comment - Another thought would be to provide a variable syntax for annotation values. For example: @Table(name="$ {TBL_NAME} "). OpenJPA could do runtime variable replacement while processing metadata and/or mapping information using system variables or some other means. This leads to the issue of finding a variable syntax that isn't a valid table name on some platform. But, a configuration setting could be used to enable/disable the feature altogether.

          People

          • Assignee:
            Unassigned
            Reporter:
            Hugh
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:

              Development