Bug with multiple ManyToMany relationships

[astro75]

My model has multiple ManyToMany fields like this:

class MyObject extends Object 
{
    public var categories:ManyToMany<MyObject,Category>;
    public var languages:ManyToMany<MyObject,Language>;
}

When I parse json data that contains multiple objects this relationship works correctly only for first object.

for(...) {
  for(...) {
    ...
    o.languages.add(language);
  }
  for(...) {
    ...
    o.categories.add(category);
  }
}

For following objects relationships go to Category join table when they should go to Language join table. When I swap inner cycles then all relationships go to Language join table.

[jasononeil]

Hmmm that's not good. I have at least one model where it is working for me.

Which platform are you targeting? PHP, Neko or other?

Any chance you can post the source code for Category or Language so I can test? Even if it is a minimal reproducible test case... Jason

On 09/10/2013 8:12 AM, "astro75" notifications@github.com wrote:

My model has multiple ManyToMany fields like this:

class MyObject extends Object { public var categories:ManyToMany<MyObject,Category>; public var languages:ManyToMany<MyObject,Language>; }

When I parse json data that contains multiple objects this relationship works correctly only for first object.

for(...) { for(...) { ... o.languages.add(language); } for(...) { ... o.categories.add(category); } }

For following objects relationships go to Category join table when they should go to Language join table. When I swap inner cycles then all relationships go to Language join table.

— Reply to this email directly or view it on GitHubhttps://github.com/ufront/ufront-orm/issues/1 .

[astro75]

I use windows with neko target and nekotools server. Here is a complete project for this problem https://www.dropbox.com/s/fv68u7sypdrek0w/implementation.zip build with server.hxml, create table with ufadmin and run either /test1 or /test2. On database I get 1 field on one table and 19 fields on the other.

[jasononeil]

Not sure when I fixed this, but it passes now - and I've added a test case for it.

See 67085ad048198af0783b62ef44c8fbd8d2f2b50f