DataNucleus JIRA is now in read-only mode. Raise any new issues in GitHub against the plugin that it applies to. DataNucleus JIRA will remain for the foreseeable future but will eventually be discontinued
Issue Details (XML | Word | Printable)

Type: Bug Bug
Status: Closed Closed
Resolution: Won't Fix
Priority: Minor Minor
Assignee: Unassigned
Reporter: Mike
Votes: 0
Watchers: 1

If you were logged in you would be able to see more operations.
DataNucleus Store RDBMS

Multiple 1-N Relation's with the same name gives an _IDX error

Created: 05/Sep/11 12:05 AM   Updated: 10/Jan/12 06:29 AM   Resolved: 05/Sep/11 06:58 AM
Component/s: ORM
Affects Version/s: 3.0.1
Fix Version/s: None

Datastore: MySQL

 Description  « Hide
I am using datanucleus-JDO with the following classes:

public class Stock {
  private Login login;
  private StockGroup stockGroup;

public class Login {
  @Persistent(mappedBy = "login")
  public List<Stock> stocks;

public class StockGroup {
  @Persistent(mappedBy = "stockGroup")
  private List<Stock> stocks;

This works when using mongoDB for example, but fails when using MySQL as a backend:

Insert of object "sw.entity.Stock@6df29680" using statement "INSERT INTO `STOCK` (... ,`STOCKS_INTEGER_IDX`,`STOCKS_INTEGER_IDX`) VALUES (?,?,?,?,?,?,?,?,?,?,?,?,?,?)"
failed : Column 'STOCKS_INTEGER_IDX' specified twice

When I change the names of the fields stocks to loginStocks and groupStocks for MySQL it works, since different _IDX columnname's are generated, but I think this is a bug.

Sort Order: Ascending order - Click to sort in descending order
Andy Jefferson added a comment - 05/Sep/11 06:58 AM
User can easily specify the column names as per @Column or in XML metadata, and this is what is defined clearly in the docs and JDO spec

renfeng added a comment - 09/Jan/12 06:20 PM
Hi Andy

I've met the same problem. I found two workarounds:

1. use a join table instead of foreign keys, or
2. rename the fields

However, I vote against the second because it's mean to be data store independent to have jdo and datanucleus in the first place. I don't like the first much either because additional join tables look redundant.

Do you think it's reasonable to change column names, <fl>_INTEGER_IDX, to <fl>_<obj>_IDX, so it'll be consistent with <fl>_<obj>_ID_OID? (fl is the name of a field belonging to the object obj) For example, the duplicate column names, STOCKS_INTEGER_IDX and STOCKS_INTEGER_IDX, will be STOCKS_LOGIN_IDX and STOCKS_STOCKGROUP_IDX.


Andy Jefferson added a comment - 09/Jan/12 07:46 PM
No plans to change anything, as per the original close messages.
Obviously a user could define their own "identifier factory" (plugin point), use it (and test it), and then contribute it (via JIRA) as an alternative. That would of course mean that someone other than me has to do something :-)

renfeng added a comment - 10/Jan/12 03:25 AM
Thanks for showing me the way to the plugins. Can you stay with me for a further problem?

I followed the guide,

and I verified that the behavior described here

is not the fact I observed:

 * the document says "datanucleus2 IdentifierFactory (default for JDO persistence)" and "Any index column in a List will be called IDX", but
 * what I have in my MySQL database is "Any index column in a List will be called INTEGER_IDX", which is the result of "datanucleus1 IdentifierFactory (used in DataNucleus v1)"

I tried to set explicitly datanucleus.identifierFactory=datanucleus2 in my file, and I tried to wire manually by creating a plugin, but the result stays the same.

Thanks again.

renfeng added a comment - 10/Jan/12 04:18 AM
I found that the identifier factory is only in effect when using join tables, not for foreign keys.

BTW. Field renaming also only works for join tables, not for foreign keys.

May I ask is this a bug or a feature?

Andy Jefferson added a comment - 10/Jan/12 06:29 AM
As already said, nothing is going to change (in DN3.0 as a minimum) ... people rely on the defaults. If you think identifier factory isn't used for that index then you need to contribute code so it is used, and then provide an alternative identifier factory. That way there would be a backwards compatible change, so people using the current default can continue to use it. Nothing else will be contemplated.