Now that Apple is trying to force us to use Xcode 4, I'm in front of a problem: it seems Xmo'd doesn't work with this major Xcode release. Is there a solution for that out there? If not, are you planning on adding the support for Xcode 4 anytime soon? Can I help on that?

Running mogenerator with 3.2.3 and when I save the model I get the following error in the console.

7/2/10 10:05:23 AM [0x0-0x5a75a7].com.apple.Xcode[33556] osascript: couldn't save changes to script /Developer/Library/Xcode/Plug-ins/Xmod.pbplugin/Contents/Resources/Scripts/Xmod.scpt: Permission denied

The command:

mogenerator -m PlantEditor.xcdatamodeld/PlantEditor.xcdatamodel -template-path ~/Library/Application\ Support/mogenerator —template-var arc=true

or any variation of it (with or without template path), different order of arguments, etc. never produced ARC compliant classes. As a quick workaround I had to edit the machine.h.motemplate.

This is true for the latest sources as well as latest official release.

Hi. I quite confused about swift support.

1. according this line: https://github.com/rentzsch/mogenerator/blob/master/mogenerator.m#L726 I should write --swift option.
2. according link in beginning of your readme: http://stackoverflow.com/questions/3589247/how-do-the-mogenerator-parameters-work-which-can-i-send-via-xcode there is no mention about swift at all.
3. also according readme you mention that we should use --v3 option to generate in swift. There is also mention about some to-one relationships bug - is there issue related to this bug? how better to track resolution of this bug?
4. And finally, I found, that you have swift12 branch. Is it better to build your project from this branch to use it in swift project?

Swift classes in frameworks/dynamic libraries are inaccessible to clients unless they and their public API are declared public. A class may not be made public unless its superclass is also public.

So: If you want to expose MyMogeneratedClass in a dynamic library, you must also declare _MyMogeneratedClass public. This requires hand-editing _MyMogeneratedClass.swift, which defeats the purpose of machine-generated classes.

This revision adds the public qualifier to the class and @NSManaged properties in machine.swift.motemplate.

Bugs

A subtler implementation might add a command-line argument to suppress or otherwise refine the use of public. However:

1. Nobody needs more command-line arguments. Ever.
2. Risk of accidental collisions between framework and client code is small (absent in Swift).
3. @objc methods are introspectable whether defined in Swift or Objective-C. “Unauthorized” access to private API is a ship that sailed thirty years ago. Details too numerous to state here.
4. See the next section: You can’t unit-test a mogenerated class without making it public.

Testing

The rake-mediated test suite in test/ passes. In my haste, I haven’t figured out whether MogenSwiftTest has anything to do with the integrity of the product. Possibly not, or not recently, as it relies on the WWDC dialect of Swift rather than that in Xcode 6.1.

With modifications (which included a lot of public tags to expose the classes under test to the test module), the Test action yields a pass on all tests.

The latest public release (1.27) asserts in -[MOGeneratorApp setModel:] for a stupid-simple xcdatamodeld. This is fixed in the latest revision, (e8a05a316), but I have to explain mogenerator to a readership that can't be trusted to clone a Git repo.

Supplying the .xcdatamodel inside the .xcdatamodeld cures the problem in 1.27.

The notes for 1.27 advertise the handling of .xcdatamodeld as an enhancement in that release.

Can a 1.28 possibly be packaged-up in the next few weeks?

Always recognizing I may be doing something boneheaded.

Sample project in Dropbox.

$ mogenerator -v
mogenerator 1.27. By Jonathan 'Wolf' Rentzsch + friends.

$ pwd
/Users/fritza/Desktop/KillMeMogenerator/KillMeMogenerator

$ ls
Base.lproj          KillMeMogenerator-Info.plist
Images.xcassets         KillMeMogenerator-Prefix.pch
KMGAppDelegate.h        Model.xcdatamodeld
KMGAppDelegate.m        en.lproj
KMGViewController.h     main.m
KMGViewController.m

$ mogenerator --model Model.xcdatamodeld/
Assertion failed: (model), function -[MOGeneratorApp setModel:], file /Users/wolf/code/github/mogenerator/mogenerator.m, line 681.
Abort trap: 6

$ mogenerator --model Model.xcdatamodeld/Model.xcdatamodel/
4 machine files and 4 human files generated.

$ 

My VectorLayer object has an ordered to-many relationship to VectorStroke named strokes. I cannot seem to add a VectorStroke to my VectorLayer without it crashing.

I've tried adding a VectorStroke to the VectorLayer directly with the following results: [vectorLayer addStrokesObject:vectorStroke];

* Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '* -[NSSet intersectsSet:]: set argument is not an NSSet'

And I've tried using the strokesSet property and got the following results: [vectorLayer.strokesSet addObject:vectorStroke];

*** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: 'NSManagedObjects of entity 'VectorLayer' do not support -mutableSetValueForKey: for the property 'strokes''

Am I doing something wrong or is this a bug?

These two class methods are synthesized by mogenerator, so they should only override when hasSuperentity, not when hasCustomSuperentity (which also returns true when a custom base class is specified).

Fixes #253

This great project seems a bit dead, let's try to get a little bit of life back into it. How can we get 1.28 released?

I don't think that we have to worry too much about backwards compatibility, people can always use the old version to generate their files.

So where do we start?

HEAD appears to use clang, and builds fine under Xcode 4, but I’d prefer to keep the homebrew distro using tagged, stable releases.

Ergo: is 1.23 around the corner?

Three major changes in this one:

Inverse relationships are more Core Data like

In the case where you have, for example:

Employee has one Department
Department has many Employees

If you tried to do: [anEmployee setDepartment: aDepartment]; It would fail to set the inverse "many" relationship (i.e add anEmployee to the employees array). I've made a few changes to the PONSO template to correct this behaviour. I've taken steps to ensure that it won't infinite loop!

Fixed a memory leak when the "many" relationship in a one-to-many is Transient

In the case above, if it was configured as such:

Employee has one Department [Non-Transient]
Department has many Employees [Transient]

Employees would be added to an NSArray, and by default, NSArrays retain any objects added to them. This results in an unexpected memory leak (since one would assume that making it transient, like for the "one" side, causes it to be "assigned"). I've fixed this by using a trick when creating the NSMutableArray (or NSMutableSet, see below) - using CFArrayCreateMutable, you can set the "retain" and "release" functions to NULL to prevent it from calling retain and release on added objects. Since this makes use of the Toll-free bridge, it will cause issues with ARC projects.

NSSet-based PONSO Templates

I've also added a sub-directory to the PONSO templates folder which is basically the same as the NSArray ones except it uses NSSet instead of NSArray. This is particularly useful, since along with my changes to inverse relationships, with NSArrays, the following code would result in unexpected behaviour: [anEmployee setDepartment: aDepartment]; [anEmployee setDepartment: aDepartment]; You'd end up with the employees array containing anEmployee twice, which may not be what the developer was expecting. Using the NSSet-based templates gets around this issue since NSSets only accept unique objects.

Expected Behavior

The Wiki for Template Variables / NSEntityDescription lists abstract in the table. https://github.com/rentzsch/mogenerator/wiki/Template-Variables#nsentitydescription

Actual Behavior

The table should read isAbstract instead of abstract

Summary of Changes

Machine Swift template had several long standing issues, one of which was absolutely incorrect and some that needed updates or improvements.

Specifically, the mutable relationship accessors were not correct: they just returned a mutable copy of a set instead of returning the actual underlying mutable set provided by the APIs (and where are correctly implemented in the Obj-C code).

Later these same accessors were used in manually written add/removeObjects accessors, which while worked was not done using underlying collections and thus less efficient. Also, these accessors are now generated by the compiler, using @NSManaged attribute. See #332 .

Addresses

#332

Hello

In addition to Homebrew, could you support MacPorts as a distribution method?

Homebrew is widely used by freelancers but is a complete mess to use at scale with managed fleet of Macs. And the Homebrew team repeatedly shown disrespect to Apple guidelines leading their system to break other software on the device.

Homebrew has a long history of issue proving it's not an enterprise grade distribution system unlike MacPorts.

With support for MacPorts, Mac Admins would also be able to generate a pkg from your port to distribute it via fleet management solution, without the need of a port solution on the endpoint.

That would be a really great addition to the long standing reference mogenerator.

And thanks a lot for your work!

Summary of Changes

This incorporates a variety of updates to generated Swift code. Objective-C generated code is not affected by this PR. Changes are listed in the updated README and below.

This does not include Codable support for NSManagedObject subclasses, which has been shelved for now.

Addresses

• [NEW] Update Swift templates for better Swift style (Aleksandar Vacić)

• [FIX] Fixed invalid call of NSManagedObject.fetchRequest() (Vincent Esche)

• [NEW] Add support for URI and UUID attribute types (Trevor Squires)

• [NEW] Expose information when custom type is set through userInfo (Aleksandar Vacić)

• [NEW] Add Codable property support via a new attributeCodableTypeName user info key (Tom Harrington)

• [CHANGE] Nullability annotations for generated primitive accessors (Michael Babin)

• [FIX] Support for “Uses Scalar Type” (Rok Gregorič)

• [FIX] Swift 3 NSData to Data (Christopher Rogers)

• [FIX] Add specialized fetchRequest() func to Swift's machine generated files (0xpablo)

• [FIX] Correct Swift machine template for singleton (fetchOne…) fetch request results (Warren Burton)

• [FIX] Expose allAttributes and allRelationships (Trevor Squires)

Feature Request

I'd like to see the template create +fetch<Foo>Request methods that return an NSFetchRequest so that I can modify it, in code, before executing it.

Additional Information

I have a modified template pair that does this. Are you interested in a PR? Should I wrap it in a template variable (to optionally disable/enable it)?

Hi there,

the generated classes do have the NSNumber type for bool an double values. In xcode there is a way to check "Use scalar properties for primitive data types" - is there a way to realize this with mogenerator, too?

I want to use model.isCkecked = YES to set the value for a bool.