I'm having an object graph which contains several entities. i'm facing a situation where one entity can change several times but i need a way to revert it to the original state. Using some kind of undo/redo will probably not work well since other entities could change as well but i dont want to revert them.
I was thinking to just insert the changed object "naked" without any relationships. So the original one will stay in the object Graph and the changes will be floating alone.
Another way would be to change my Model so the object would be an Array. Within this i could save both and add some kind of identifier to recognize the appropriate object. However sometimes i need to replace the whole Graph and then i need to merge the changes.
I really feeling stuck with this Problem. Any help is appreciated.
Related
i'm refactoring my app. Currently, I store objects in a .plist for further processing. It works fine, but I thought it was about time to dive into CoreData.
My app fetches data from a web service. This data I parse into individual objects.
I use the properties of these objects to fill Tableviews.
While refactoring, I could just bluntly store the whole object as a transformable with CoreData, as far as I understand.
I could also define an entity with attributes similar to the properties of my object.
Is there any Best Practice here? I think the first approach makes it easier to do the refactoring, but I somehow think I'm missing out on advantages of CoraData in that case. Like maybe performance?
Do not store objects as transformable. You will get just DB where it is not possible to fetch some separated objects based on some criteria. You will need to fetch all DB in memory and than work with it. So it will be the same as plist file and you will waste the effort. Just use entities with proper attributes. CoreData is fast, you don't need to worry about performance.
Transformables are generally a good idea only for attributes that Core Data doesn't know how to represent. They let you use a binary data blob as a fallback, but they're never ideal. They can also be used if you absolutely, definitely, will never ever need to filter or sort a fetch request based on the attribute value. In that case they're still not great, because there's extra unnecessary work.
If you need to (or might possibly someday need to) filter or sort a fetch request based on attribute values, don't use a transformable. They can't be used for either purpose beyond extremely basic stuff like checking to see if the value is nil.
OK, I owe you.
I asked a question without investigating things properly.
The real answer is to understand NSManagedObjects.
Sorry for bothering you
Please, can someone help me with problem i have.
I use singleton object for operations with Core Data. I want to be able to create an object and save it, but I don't want to save whole context, just newly created object. And I want that data to be seen right away.
Many people had problems with nested contexts, so I guessed it would be better if I used multiple persistent stores with same context, correct me if I'm wrong.
So, is having many stores and just switching between them the right way to save certain objects?
I have two entities:
Profiles<-->>Events
Now, I want the user to be able to add a profile and then be able to add events to that profile.
I'm having a hard time getting my mind out of the relational database world and into core data, but as I understand it, whenever I add an Event, I'll have to set the relationship for the profile..which makes sense to me. But when I add the Profile initially, do I have to tell the Event entity anything, or does core data resolve that when I add an Event?
You really need to read the Core Data guide from start to finish. It answers all these questions, and will save you a ton of headache. I'm a big fan of Core Data, but it is a massive framework that cannot be learned by puttering around and just trying things on your own (that is what I tried first as well, and got very frustrated and wasted more time undoing what I thought I had learned). Most importantly, don't think of CD as an ORM or database mapper - it's really an object graph manager that also handles persisting that object graph for you (as well as undo management, object 'schema' evolution, and more)
The short answer to your question is that no, you don't have to tell CD everything about your objects right away. You can create a Profile, set a few attributes on it, save it, come back days later and then start adding Events that are related.
Yes Ryan core data is different from relational DB , in your example you can add the event separately and after that you can add the relation to the profile in different command .
[_profile1 addEventObject:_event1]
[_profile1 addEventObject:_event2]
[_profile1 addEventObject:_event3]
I'm developing a business web application which will maintain a database with several tables. One of the requirements are that one should be able to "save your work" without affecting the database and then later pick it up and continue working. Multiple "savings" must be supported.
This administration tool will be developed in ASP.NET MVC4 or Microsoft's LightSwitch, I haven't decided yet.
The problem I have is that I don't know how to solve this structurally, are there any known techniques to this problem? I need help by someone to point me in the right direction, I'm stuck here..
EDIT: I'll try to explain further with a scenario
I make a change to one row and save, but the change should only be visible to me (not affect the main database).
I realize the change in 1. is bad and choose to start over with changing the data in the same row, I also make a change to another row. I save these changes (but only for me)
Now I have two savings (from step 1 and 2), I change my mind and the changes made in 1. is correct and I open that "savefile" and commit the changes to main databse. I'll then delete the "savefile" from step 2.
Hope that makes the situation more clear.
Thanks
The easiest way that I can think of is to let the database do the work for you.
You could:
Just add some type of a "status" column ("committed", "uncommitted" etc) to the table, & filter out any "uncommitted" records in any grid that displays "real" data. You can then also filter
a different way in your editing grid, that only shows you
"uncommitted" records, or if you could save an ID instead of a status, if you
only want to see your own records.
Add another table to hold the uncommitted records, rather than
"pollute" the actual table with extra columns.
Does that make sense?
if you are really going to build a transactional type version control system, then you have a huge job ahead.
look at some popular tools like SVN and see the level of complication and features they support.
Rolling back a partial transaction inside a database - especially one with constraints and triggers will be very difficult. almost everything would run into an issue somewhere.
you may also consider storing uncommitted transactions outside the database - like in some local XML structure - then committing the components only once when desired.
either way, the interface for finding all the records and determining which ones to do what with will be a challenge - nevermind the original application.
I use disablecontrols method for master/detail tables and I am looking for a way to change the record position internally (while within disable controls) in the component level (IBDAC) without using bookmarks or locate
Thanks
Try RecNo and check out Navigating Data in Client Datasets
Apart from that, I think this is probably a design issue you need to address, but I'm not sure. I normally fetch all the data I need, then a single unidirectional pass through the dataset is usually enough. If necessary, make a second pass (rarely), but I've never had to move back and forth several times within a dataset. There is probably a better way. Hope that helps.