Unable to generate ordered relationships with feature/swift12 branch

[tomburns]

I'm having some difficulty getting mogenerator to generate correct machine classes for entities with ordered relationships. It's entirely possible that I'm missing something here, but every time I build feature/swift12 from HEAD and generate classes I end up with plain sets as opposed to the ordered sets I would expect.

I've created a sample project in which an ordered one-to-many relationship goes undetected: https://github.com/tomburns/CoreDataTest

It's entirely possible that I'm missing something; by all means let me know if this is a boneheaded mistake on my end!

for reference, the project was created with Xcode 6.3.2 and this is the mogenerator invocation i've been using:
~/bin/mogenerator --v2 --swift --model CoreDataTest/CoreDataTest.xcdatamodeld --output-dir CoreDataTest/

[tomburns]

Anyone able to reproduce this? Am I holding it wrong? @justin @atomicbird

[tomburns]

@justin (tagging you since you expressed an interest on twitter)

I dug into this a bit more this afternoon, setting some breakpoints in mogenerator's jr_isOrdered and interrogating the relationships. For some reason, NSRelationshipDescriptions that return YES for isOrdered in my app seem to be returning NO when mogenerator is run. This is occurring both with the sample app I linked above and my main application in which I discovered the issue.

[tomburns]

LLDB output from within mogenerator:

(lldb) po [[model.entitiesByName objectForKey:@"Parent"] relationshipsByName]
{
    children = "(<NSRelationshipDescription: 0x100315080>), name children, isOptional 1, isTransient 0, entity Parent, renamingIdentifier children, validation predicates (), 
warnings (), versionHashModifier (null)\n userInfo {},
 destination entity Child, inverseRelationship parent,
 minCount 1, maxCount 0, isOrdered 0, deleteRule 1";
}

and the same relationship from the same model, from within the app:

(lldb) po mom.entities[1].relationshipsByName
[children: (<NSRelationshipDescription: 0x7f931af254d0>), name children, isOptional 1, isTransient 0, entity Parent, renamingIdentifier children, validation predicates (),
 warnings (), versionHashModifier (null) userInfo {}, 
destination entity Child, inverseRelationship parent, 
minCount 0, maxCount 0, isOrdered 1, deleteRule 1]

[otaran]

Hi @tomburns, I am also able to reproduce this bug. I used git-bisect and found out that this is a regression introduced in f0b1b32. /cc @atomicbird

[otaran]

Excuse me @atomicbird, I read over your commit again and figured out you've completely reimplemented model parsing – great work!

[tomburns]

Yep, looks like it was introduced when the internal parser fork was merged at 73fccca.

@justin, @atomicbird, any thoughts on otaran's fix proposed above? I'm happy if it solves my immediate issue, but are there any tests which might indicate that other model features may not be picked up by the new parser?

fwiw, the ./test/ suite comes back clean when run against feature/swift12 HEAD:

~/c/s/m/test (feature/swift12) rake
*** Clean-building mogenerator
*** Testing MRC (with objc literals)
success
*** Testing MRC (without objc literals)
success
*** Testing ARC (with objc literals)
success
*** Testing ARC (without objc literals)
success

[justin]

This should be taken care of now.