Using Xcode 6 beta 4 Core Data, how do you regenerate the subclasses if you want to add/remove an Attribute?
For example, I create a new entity and add a few attributes then go to Editor > CreateNSManagedObjectSubclass.., it works the first time and creates the entity as a .swift file, but then if I go and add a new entity and try to regenerate the subclasses by choosing the same option in the editor menu it doesn't overwrite the .swift file with the new entity. This used to work for me in Xcode 5.
Does anyone know what I'm doing wrong or what is the correct way to do this?
Thanks!
Xcode won't silently overwrite your file. This is a feature, not a bug, because you will not inadvertently lose custom code in those classes.
If you want to replace the file, delete it first. The class generation will then work as expected.
Related
Suppose we have an Android project with Doppl integrated. We set up the Xcode workspace via pod install, write some Swift, and everything is working fine.
Now, we add a method to a Java class that is part of the Doppl translation, such as a unit test class. We run dopplBuild (with Xcode closed for safety), reopen the Xcode workspace, and everything is working fine, including the new method.
However, when we try changing the mix of classes, that flow (dopplBuild, reopen Xcode) appears to be insufficient. For example, if we add another unit test class (including adding it to dopplConfig), our test runner can't find it. If we remove a class from translatePattern and testIdentifier, and are no longer referring to it from our code, the Xcode build fails because it thinks that class should still be there.
What should we be doing to get Xcode to know about these bigger changes?
Run pod update. While you do not appear to need this for the smaller changes (adding/removing methods, changing method implementations), you do need it when you wind up adding or removing classes from what you had previously.
Also note that pod update does not change anything else, such as any dopplTests.txt file that you may have copied into your workspace. You will need to update those separately yourself by hand.
With others types, like classes or properties it works to rename object. But for individual I can't find such option.
Is it possible to rename individual without deleting and recreating it? And if not, why?
In order to rename an individual or any other entity on Protégé you will need to click on the entity and choose: Refactor -> Rename Entity...
This will open the following dialog where you can enter the new name:
Another way of doing this is clicking the entity and then pressing Ctr + U, this shortcut will open the same dialog (and it's way faster if you have to rename many things).
Found a solution
Select the entity and go to the top menu - Refactor > Rename Entity and you'll get a renaming dialogue.
Renaming a named individual is the same as renaming any other entity from OWLAPI, so if you can't find it in the UI it might just be a missing functionality.
If you wish to write Java code with the owlapi, you can use OWLEntityRenamer.
Editing with an XML tool will also work, for XML formats - however the operations will be different for rdf/XML and owl/XML.
Plain text editing will also work. Pay attention to name changes that also change the namespace, though - it might require changes in the declared entities.
Haven't found any capabilities to edit from UI, but it's possible to edit from any XML-editor
Another option is to create a slot "name" then go to the instance you created and give the name you wish.
To display the instance with the name you just gave go to the instance browser->menu->select display slot->choose name.You can see here a screenshot which will make it clear!
I am using Liferay 6.2 GA5 Community Edition.
Sample case I have 2 entities in my service.xml, let's say entity A & B.
When I run Service Builder then it will generate many JAVA files in my source code, and also generate JAR file located in
".\my-app\liferay-plugins-sdk-6.2\portlets\my-app-portlet\docroot\WEB-INF\lib\my-app-service.jar"
I open it with 7-zip, and I can see in package com.mycompany.myapp.model contains classes of entity A & B.
Then I try to remove entity A in service.xml, and I have removed the corresponding JAVA files generated in my source code, then I run Service Builder again, but inside my-app-service.jar, entity A is still exist.
How do I completely remove it from JAR file? because in my case, Service Builder will not remove it, although I have remove generated JAVA files manually.
ServiceBuilder is a code generator, thus it only generates new code.
If you want to get rid of the once generated code, there's a lot more than just the java classes to get rid of: Spring configuration, Hibernate configuration etc. are there as well for you to take care of. All of these will have to be deleted manually. And if the code still remains in the jar, good old ant clean (or whatever build environment you use) should get rid of the my-app-service.jar file (which you otherwise also can also just delete manually, so that it will be rebuilt next time a build process or ServiceBuilder runs)
I recommend searching for occurrences of A in all your project's files to see if you still find leftovers, because otherwise some component might complain at runtime that a declarated class can't be found.
I'm trying to generate NSManagedModels from my datamodel. Generation works but after I got many errors :
error: filename "Station+CoreDataProperties.swift" used twice:
'/Users/Me/MyApp/Models/CoreData/Station+CoreDataProperties.swift' and
'/Users/Me/Library/Developer/Xcode/DerivedData/MyApp-gwacspwrsnabomertjnqfbuhjvwc/Build/Intermediates/MyApp.build/Debug-iphoneos/MyApp.build/DerivedSources/CoreDataGenerated/Model/Station+CoreDataProperties.swift'
:0: note: filenames are used to distinguish private
declarations with the same name
I try clean build folder and derivedData directory hard delete. I'm using Xcode 8 BETA maybe it's a bug ?
I get this in Xcode 8.1
For me following steps solved the issue. Please note that order matters.
1) Create entity in Core Data model.
2) Under class section, make settings as on following image.
Module: Current Product Name
Codegen: Manual/None
3) Generate your NSManagedObject subclass.
This post greatly helped me solve this problem myself. Personally I look at this as an Xcode bug. Bug or not this is a huge chicken and egg situation.
I ran into this by:
Created a new Project using Core Data
Generated my NSManagedObject subclass+extension (while codegen: ClassDefinition)
I accidentally saved the generated classes in the Wrong folder
I deleted the generated files
Re-generated in folder I wanted
💥- Xcode used twice errors
As others have posted I kept cleaning my build (and clean build folder) but that never fixed the build issue.
I finally figured out if you originally created your NSManagedObject generated classes with codegen: ClassDefinition, as I did without knowing then you are locked in for the chicken and egg issue.
I then deleted the auto generated classes thinking I had to re-generate, so I did. Once re-generated I would get the used twice build error again. I manually went into the ../DerivedSources/CoreDataGenerated/Model/.. and deleted the duplicates. Again, I re-generated thinking I'd only have 1 copy (in my project) but I was wrong. If codegen: ClassDefinition was originally set then Xcode will keep creating the auto-generated classes+extensions and put them in the buried folder ../DerivedSources/CoreDataGenerated/Model/... I repeated this chicken and egg a few times before catching on.
I later realized you do indeed need to mark codegen: Manual/None however to get things back in sync you need to delete the auto-generated files in ../DerivedSources/CoreDataGenerated/Model/.. and in your project if you have any there still.
Be careful setting codegen: Manual/None, for me it was bit tricky because codegen: Manual/None wouldn't stick. I had to click back and forth between entities multiple times to double/triple check each entity was set to codegen: Manual/None. Then auto generate the files. At this point your only copy of the auto generated files should be in your project and not in ../DerivedSources/CoreDataGenerated/Model/...
Last, I think this is a bug because if you specify codegen: Manual/None I don't expect Xcode to auto generate files at all, yet it does and puts them in your project. More confusing if your setting is codegen: ClassDefinition, who the heck knows Xcode will put the files in a buried directory yet it is available for use in your project. My beef with this is the auto generated files aren't source controlled and if I change computer I have to know to auto-generate them on the new station.
Hope this helps someone else!
Cheers!
This is indeed not a bug. As #Morrowless suggests both class definition and properties extension are created. If this is not wanted, select Manual/None under Codegen before generating the code. If the code is already generated, just delete them, and try Editor->Create NSManagedObject Subclass... again from the menu (after setting Manual/None).
Note, in the picture below, the Class Name 'Contact' is specific to my project. You will see your entity name instead.
If you generated CoreData subclasses with codegen: ClassDefinition your basically screwed. The only way to fix it is to:
Delete your CoreData subclasses.
Delete your derived data folder.
Clean your project (CMD+K).
Generate new CoreData subclasses, this time select Codegen: Manual/None and Module: Current Product Module
This is not a bug. Codegen generates these files in the DerivedData folder, so you don't need to create them again in your project, hence the compile error.
From Xcode 8.0 Release notes:
Xcode automatically generates classes or class extensions for the entities and properties in a Core Data data model. Automatic code generation is enabled and disabled on an entity by entity basis, and is enabled for all entities in new models that use the Xcode 8 file format. This feature is available for any data model that has been upgraded to the Xcode 8 format. You specify whether Xcode generates Swift or Objective-C code for a data model using the data model’s file inspector.
When automatic code generation is enabled for an entity, Xcode creates
either a class or class extension for the entity as specified in the
entity's inspector: the specified class name is used and the sources
are placed in the project’s Derived Data. For both Swift and
Objective-C, these classes are directly usable from the project’s
code. For Objective-C, an additional header file is created for all
generated entities in your model. The header file name conforms to the
naming convention “DataModelName+CoreDataModel.h”.
However, if you selected Category/Extension under the codegen pulldown menu in the data model inspector (because you want to add logic to your model): codegen will wrongly generate both the class definition and properties extension.
The solution is to simply delete the properties extension (ClassName+CoreDataProperties.swift). Your project should now compile.
After following the guidance from oyalhi and Vladimir Shutyuk, (deleting the NSManagedObject files, changing the entity codegen to Manual/None), I had to restart Xcode to allow it to index again before I could re-generate the NSManagedObject files and get a successful compile.
For the sake of completeness..:
I just ran into the same error, but none of the proposed solutions worked. What puzzled me was that even switching from automated code generation to manual for the one (as I thought) problematic entity didn't do anything.
Finally, I figured out that I had several entities with the same name, but they all shared the same classname. The reason for this was that I copy&pasted one entity several times to save me some work, because they also have a few attributes in common.
Turns out XCode renames the duplicates by adding 1, 2,... to the entity name, but leaves the class name as before. And since now entity name and class name are "unrelated", renaming the entity won't change the class name either.
Hope it helps someone - I have also filed a bug report for this.
I've began to try use Core data with swift 3 and Xcode 8 beta. When I try to generate NSManagedObject subclasses from core data model and Create NSManagedObject subclass… option in Editor menu, Xcode 8 beta generates three files one of them is _COREDATA_DATAMODELNAME_+CoreDataModel.swift with the following content:
import Foundation
import CoreData
___COREDATA_DATAMODEL_MANAGEDOBJECTCLASSES_IMPLEMENTATIONS___
In addition, the content of this file shows two warnings:
Expressions are not allowed at the top level.
Use of unresolved identifier '___COREDATA_DATAMODEL_MANAGEDOBJECTCLASSES_IMPLEMENTATIONS___'
Has anyones faced the same issue? Which is the meaning of this new file?
Thanks
It's probably a (beta) clash with the new automatic subclass generation, which can be controlled in the entity inspector of the data model file.
From the documentation (What's New In Core Data)
Xcode automatic subclass generation
Xcode now supports automatic generation of NSManagedObject subclasses
in the modeling tool. In the entity inspector:
Manual/None is the default, and previous behavior; in this case you
should implement your own subclass or use NSManagedObject.
Category/Extension generates a class extension in a file named like
ClassName+CoreDataGeneratedProperties. You need to declare/implement
the main class (if in Obj-C, via a header the extension can import
named ClassName.h). -
Class Definition generates subclass files named
like ClassName+CoreDataClass as well as the files generated for
Category/Extension.
The generated files are placed in DerivedData and
rebuilt on the first build after the model is saved. They are also
indexed by Xcode, so command-clicking on references and fast-opening
by filename works.
I have similar problems with this developer beta Xcode 8. Some of them resolved Command + S (save changes) before I leave Data Model or before I generate NSManagedObject subclasses. I don't know why but in my case automatic save didn't work sometimes and some errors occur.
I've run into the problem with the .swift file cited above and found that commenting out the ___COREDATA... line got me by the error for now. I'm not sure what it's supposed to accomplish.
I'm also finding that XCODE 8 has a tendency to forget about new fields that are added to CoreData entities and to repeatedly reset the CoreData model code generation target to Objective C, leading to a flurry of .h and .m files instead of swift files when it regenerates files. Most of the issues that I've seen have been CoreData related, but have been workable so far.
Other than that, XCODE 8 has been surprisingly solid working with an app with 25 data entities and over 30 view controllers so I'm not complaining.