CoreData: Save Modified Managed Object as New Object - core-data

My app allows a user to edit data, but during save there are two things that can happen:
If the name of the data stayed the same, just save the object as an edited version. I.e. they are just editing the existing object.
However, if they have changed the name, this should create a new instance and restore the edited data to the original.
Obviously, 1 is the easy case and is working just fine. But I'm conflicted about the best method to handle 2. How best is it to save a modified NSManagedObject as a new row in the DB?

There is no obvious way to just "copy" a NSManagedObject. The most robust way is to simply recreate everything from scratch.
Make sure you have all the changed attributes stored separately (here I am assuming they are in various text fields or that they are unchanged from the existing object). You can make this decision (new instance or not) when your editing view controller is dismissed:
if (![nameTextField.text isEqualToString:object.name]) {
ObjectClass *newObject = [NSEntityDescription
insertNewObjectForEntityForName:#"ObjectClass"
inManagedObjectContext:self.managedObjectContext];
newObject.name = nameTextField.text;
newObject.attribute1 = oldObject.attribute1;
// or
newObject.attribute1 = attribute1TextField.text;
// do this for all attributes
[self.managedObjectContext save:nil];
}

Related

Revit API reopen form an keep data

I would like to make a Plugin where the user can select a source and then a target element and get all the parameters and their values.
My problem is: After I selected the source element and got all parameters and values into comboboxes I select the target (via another button). For that the form closes again and after selecting and reopening all the data from the source element is gone.
What would be a correct way to do this?
At this time both buttons close the form run another ExternalEvent to select the element and collect the data.
Can I cache this data (Lists, dictionary with list, dictionary with dictionary with list) or do I have to write it to a file or is there another way?
How do I keep/remember the data I collected when a form closes an reopens?
Thank you for any help
Philipp
There multiple ways of doing this I guess. It is more of a general programming rather than API issue. You basically need to keep the data in memory outside of just the WPF window.
Some options of the top of my head would be
Save the data into file in temp folder and read it when needed (probably a messy solution)
Create & instantiate a class with data to keep in memory and communicate it between different windows etc.
Have a Static Class with appropriate property. Once selecting an element assign it to the property. This should persist within the Revit session. Static Class.
Option 3 should be the easiest to use.
Just use Properties -> Application settings to store the ID of the entity. Then on launch get the combo boxes to auto populate if the ID can be found.
External events are only required when editing the model.
This is assuming your using Visual studio and not sharp develop. If your still using sharp develop it is time to move on to a real IDE.
I think there are a few options. You could use the built in DataStorage that a revit model provides. Here, i made a datastorage entity to store a GUID for a project...
public Guid schemaGuid = new Guid("{5F374308-9C59-42AE-ACC3-A77EF45EC146}");
public DataStorage dataStorage;
public string schemaName = "UniqueProjectId";
public DataStorage dataStorage;
public string SimpleField = "MyProjects_GUID";
public Schema CreateNewDataStorage()
{
Guid newProjectGuid = Guid.NewGuid();
Transaction t = new Transaction(doc, "Make internal storage");
t.Start();
dataStorage = DataStorage.Create(doc);
dataStorage.Name = schemaName;
SchemaBuilder schemaBuilder = new SchemaBuilder(schemaGuid);
schemaBuilder.SetSchemaName(schemaName);
schemaBuilder.AddSimpleField(SimpleField, typeof(Guid));
schema = schemaBuilder.Finish();
entity = new Entity(schema);
entity.Set(SimpleField, newProjectGuid);
dataStorage.SetEntity(entity);
t.Commit();
return schema;
}
Another way would be to write to external database or text file. For something small, SQlite is easy. A temporary text file is also a very simple way to temporarily store data.
Lastly, you could use an Idling event and keep the dialogue box active.

Core-Data: fetching object count from MOC after saving

Im currently having a problem with my CoreData implementation. I try to query the number of objects with certain properties. I therefore execute the following code
NSUInteger itemsCount = [managedObjectContext countForFetchRequest:fetchRequest error:NULL];
NSLog(#"%i",(int)itemsCount);
So far so good. Everything works if i work with a fresh MOC where no data has ever been saved. The problem occures when i do the following:
I save the whole MOC
Delete one of those objects matching the fetch criteria from the MOC (without saving!)
Requery the Number of objects matching the criteria
The number of objects does not change although i deleted one of the objects.
I also tried the following query ...
fetchRequest.resultType = NSCountResultType;
NSArray* array = [managedObjectContext executeFetchRequest:fetchRequest error:&fetchError];
NSLog(#"%i",[[array firstObject] intValue]);
... with the same result.
Then I tried querying the objects directly ...
fetchRequest.resultType = NSManagedObjectResultType;
array = [managedObjectContext executeFetchRequest:fetchRequest error:&fetchError];
NSLog(#"%i",(int)[array count]);
... tada: Here it works. The array does not contain the deleted object.
When I set fetchRequest.includesPendingChanges = NO, i of course get all objects because i did not save yet. The property has no effect ob the first two queries though because they show too many objects in the first place.
So my question is, what am i doing wrong and why can i not obtain the right amount of objects once i saved them to the persistence store. Do i have to reset the MOC after saving?
--------------------------------------------------------------------------------
Update
I searched further for similar problems and found some interesting posts. Fetching objects from the MOC means also querying the persistence store. Since I did not save my changes immediately, I do or don't fetch deleted and newly inserted objects respectively. But strangely this only applies for queries involving dictionary result types or count fetches. When querying the objects itself i retrieve the correct number of objects including newly inserted and without the deleted ones.
Now I am wondering on how to deal with my problem. I have a table view which smoothly works with a NSFetchedResultsController (NSFRC). I do not have to save any changes since the controller handles all the updates and notifies me. But as soon as i insert or delete data and the NSFRC notifies me, i want to do further calculations to update my other views. Those calculations include average and number of objects with certain attribute etc.
Right now I update those view as soon as an insert or delete delegate method is being called. But those queries wont return the correct values.
Calling the following before querying has no effect on those queries.
[moc processPendingChanges]
fetch.includePendingChanges = YES
Apparently my approach is lacking something. How do i fetch my needed values correctly ? Since my NSFRC obviously keeps track of deleted and inserted values im curious if it would help to create a second NSFRC just to fetch the averages and so on? Is it even capable of that?
Thanks!

microsoft dynamics crm - SQL changes

Hi I'm facing a task that requires me (or not?) to do some small changes directly on the CRM SQL DB.
Situation:
1) there was a N:1 relation between two entities that was changed to N:N.
2) For each entities I need to move related stuff from previous relation to new one.
For active entities it was no problem cause customer didn't care about changing fields "ModifiedOn", "ModifiedBy" and "ClosedOn" but for inactive (an incident that is closed for example) he'd like to migrate the related entities, but not to change these three fields. Because all those incidents are closed/inactive I cannot just call "AssociateRequest" I need to re-open case, associate, close it again. this of course will change these fields.
Is there any way to do this via the API and not directly on SQL? If not - could it be a problem?
If you already have the mechanism to change the Relationship and just need to modify the records CreatedOn, CreatedBy, ModifiedOn, and ModifiedBy...You should be able to do this using late bound code:
Entity YourTargetEntity= new Entity("YourTargetEntity");
YourTargetEntity["createdon"] = new DateTime(2015,01,01); // or whatever the date you want
YourTargetEntity["overriddencreatedon"] = new DateTime(2015,01,01); // or whatever the date you want
YourTargetEntity["createdby"] = new EntityReference("systemuser", new Guid("XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX"));
TargetEntity["modifiedby"] = new EntityReference("systemuser", new Guid("XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX"));
TargetEntity["modifiedon"] = new DateTime(2015,01,01); // or whatever the date you want
_service.Update(YourTargetEntity);
Hope that helps.

Core Data Document-based application: How do I model and control a entity that is instantiated only once per document?

I've got a few questions I've been trying to answer for myself (by hunting through the documentation) but I have a feeling I'm missing something.
Any hints (and/or pointers to appropriate documentation) would be much appreciated.
I'm building a Core Data document-based application. There are essentially two entities:
There is a single "Comparison" record associated with each document.
There are potentially many "Node" records associated with each document.
My first question is whether I'm thinking about this correctly. Since there is only a single Comparison object for each document, the attributes of the Comparison are essentially attributes of the Document itself. What (if any) is the preferred way of modeling that?
If a Comparison entity is in fact the right way to go, my next question is how and when to actually instantiate the (single) Comparison object. The user should not have to explicitly "add" the Comparison since there's going to be only one of them associated with the Document. Instead, a single Comparison object should be instantiated and inserted into the managedObjectContext. I've got something like this working already, with code in MyDocument.m that looks like this:
(void)windowControllerDidLoadNib:(NSWindowController *)windowController {
[super windowControllerDidLoadNib:windowController];
[NSEntityDescription insertNewObjectForEntityForName:#"Comparison" inManagedObjectContext:managedObjectContext];
}
However -- if the user creates a new document but then never does any work with it -- for example if he immediately clicks the close button -- then he should not be asked to "Save" the document. He should be asked to save his work only if he's actually entered any information. Is there a preferred way to implement this behavior?
I found this thread while struggling with the exact same issue. I have a table of Entity_A working in my document based Core Data app, but I need to figure out how to handle a required single-instance per document of Entity_B.
I've found something that seems to work. There's probably a better way, but this is getting me past this hurdle for now.
When the document's xib is loaded I simply check to see if an Entity_B has been created. if not, I create one and initialize its attributes.
- (void)windowControllerDidLoadNib:(NSWindowController *)aController
{
[super windowControllerDidLoadNib:aController];
//has an Entity_B been created? if not, create one.
NSError *theError = nil;
NSUInteger count = [[self managedObjectContext] countForFetchRequest:[NSFetchRequest fetchRequestWithEntityName:#"Entity_B"] error:&theError];
if( count == 0 )
{
NSManagedObject *newEntity_B = [NSEntityDescription insertNewObjectForEntityForName:#"Entity_B" inManagedObjectContext:[self managedObjectContext]];
[newEntity_B setValue:[NSNumber numberWithBool:YES] forKey:#"boolAttribute"];
[newEntity_B setValue:[NSNumber numberWithInt:2] forKey:#"intAttribute"];
}
}
I didn't insert that code snippet into the original post correctly. Trying again:
-(void)windowControllerDidLoadNib:(NSWindowController *)windowController {
[super windowControllerDidLoadNib:windowController];
[NSEntityDescription insertNewObjectForEntityForName:#"Comparison" inManagedObjectContext:managedObjectContext];
}
Your question about modelling is not very clear, can you please elaborate on what your "Comparison" entity is supposed to do and what sort of attributes you are assigning to it? It would be handy to see your "Document" entity structure so we can provide some useful input.
With regards to your second question, you could check if your NSManagedObject has been updated before deciding on whether to prompt the user to save their document or not:
if ([documentObject isUpdated]) {
...
}
More details in the documentation here http://developer.apple.com/library/mac/#documentation/Cocoa/Reference/CoreDataFramework/Classes/NSManagedObject_Class/Reference/NSManagedObject.html#//apple_ref/occ/cl/NSManagedObject
Cheers,
Rog
There isn't really a "Document" entity, I was simply using that term to refer to the overall document that is saved when the user invokes the Save menu item. Perhaps there is a better way to refer to this concept? NSPersistentDocument?
Backing up a bit... the central idea of the application is to compare two hierarchical directory structures (a visual recursive "diff").
For now the "Comparison" entity has two string attributes, pathA and pathB, which are the names of the two directories to be compared. Each "Node" entity represents the name of a file down in the directory trees that are being compared. The Node entity contains at least one attribute ("relativePath") which is the path relative to the starting point specified in the Comparison.
My first question was simply whether it makes sense for there to be a "Comparison" entity since there is going to be only one of them instantiated (at some point after the user invokes the "New" menu item).
The second question is really at what point should the single "Comparison" object be instantiated and inserted into the managedObjectContext, i.e. what method is most appropriate to make this happen?
Finally if a "Comparison" object is automatically instantiated (at awakeFromNib time, perhaps?) but the user decides not to proceed, and simply clicks the close button, he should not be prompted to save (right?) What would be the appropriate way to accomplish this? The documentObject will appear to have been updated, because an "empty" Comparison object has in fact already been inserted automatically at startup, but the user has not modified it.
Hope that's clear... thanks.

Multiple layers of MOC merges...CoreData veterans, what do you think?

Original question has been answered. Update addresses related question raised in comments.
Original post:
I am using the MOC save method used in Apple's CoreDataBooks. However, I seem to have use for two layers of MOC merging (three MOCs where the 3rd merges with the 2nd and then the 2nd merges with 1st).
First, I have a tableview (ClassList) listing school classes. Selecting a class pushes a 2-row tableview (AddClass). At AddClass, the first row allows the user to edit the class title. Selecting the second row pushes a tableview (ClassRoster) that displays the student roster for that class. Lastly, selecting a student pushes on another 2-row tableview (AddStudent) where the user can edit the student name and username.
I can add and save classes successfully by using the dual MOC merge method (managedObjectContext and addingManagedObjectContext as employed by CoreDataBooks). I will call the "base MOC" in my first view "MOC1" and call the "scratchpad" MOC "MOC2".
MOC2 temporarily stores changes made to a class object. These changes can then either be saved or canceled, sending a -didFinishWithSave:(BOOL) to the delegate. If I save, the changes made in MOC2 are merged with MOC1. That merge is working perfectly.
Handling changes made to student objects is where I'm going wrong. I thought I could employ MOC3 as a scratchpad for changes to student objects which would merge with MOC2 (when I saved a student object). MOC2 could in turn be saved with MOC1 when I saved the class object.
But I have run into errors with saving MOC3 and adding student objects to class objects because they are in different contexts. I can post code, but first I wanted to ask the bigger question: Am I going about this all the wrong way?
UPDATE:
Mr. Zarra recommended using initWithEntity:insertIntoManagedObjectContext: and setting the MOC to nil, thereby creating a temporary object which could later have its MOC set and saved.
Following his advice, I am attempting to incorporate the following code:
NSManagedObjectModel *managedObjectModel - [[managedObjectContext persistentStoreCoordinator] managedObjectModel];
NSEntityDescription *entity = [[managedObjectModel entitiesByName] objectForKey:#"MyClass"];
MyClass *newClass = [[MyClass alloc] initWithEntity:entity insertIntoManagedObjectContext:nil];
I have run into an error, but I'm not sure it is related to this code yet. I will debug and post what I find.
Yes. You do not need to use more than one NSManagedObjectContext. That example is a very poor one. In your case you should be using a single context and that will remove all of your issues.
If you want a temporary entity, create it with a nil NSManagedObjectContext. When you want to save it you call -setManagedObjectContext: and then save that NSManagedObjectContext.
The only time you realistically want to use more than one NSManagedObjectContext is when you are in a multi-threaded situation.

Resources