[
https://issues.apache.org/jira/browse/OPENJPA-1850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12923685#action_12923685
]
Michael Dick commented on OPENJPA-1850:
---------------------------------------
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.
> 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
>
> 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.
