[
https://issues.apache.org/jira/browse/OPENJPA-1850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12923893#action_12923893
]
Jeremy Bauer commented on OPENJPA-1850:
---------------------------------------
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.
> Dynamic runtime @Table name configuration
> -----------------------------------------
>
> Key: OPENJPA-1850
> URL: https://issues.apache.org/jira/browse/OPENJPA-1850
> Project: OpenJPA
> Issue Type: Improvement
> Components: usability
> Environment: All environments
> Reporter: Hugh
> Attachments: turret.zip
>
>
> 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?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
