I'm adding a "WhatIf" switch (inspired by the Powershell -WhatIf switch) to my app, that just simulates data processing, without persisting any actual data changes back to the EF storage.
The way I hoped to implement this is simply by adding a check before calling SaveChanges(), like this:
if (WhatIf == false)
efEntities.SaveChanges()
This way, the rest of the application can make changes as normal, and so long as SaveChanges() is never called, I don't have to worry about any changes being made accidentally.
Would this work? I'm worried that SaveChanges will get called by other parts of EF, such as Dispose, or something like that?
Thanks!
It will work. EF doesn't call SaveChanges itself. Developer is always responsible for persisting changes.
Related
What's the difference? When should I prefer one over another?
And some minor questions related to this:
if I have object data, when is saveObject called?
it looks like garbage collector recycles all my domino handles. I tried to downcast then clone it, but it didn't help (how does it know its still a domino object?). Is there a workaround?
if I create "var tmpVar = new package.TestClass()" from xPages, it gets recycled on update. But if I create java object from bean it stays there. Correct?
Managed beans are exactly that, managed by the XPages runtime. They are created as and when there is a first call to them. Although they have an empty constructor, managed-properties elements in the faces-config allow you to define values (and I believe you can add SSJS code to the faces-config to compute the values).
Object data sources allow you to handle what's created when, and it means they can be scoped to a smaller level than viewScope - to a Panel or Custom Control. The saveObject method is called by a Save All Datasources event. In reality, if you're coding object data sources, you'll code a button and call the relevant method rather than use a simple action.
Java variables can get recycled, but Domino objects are only recycled via two methods. The first is calling recycle() methods, the second is at the end of each request, when the session gets recycled. Because recycle() calls recycle all child elements, everything gets recycled at the end of a request. Which is why you can't store Domino objects in scoped variable or any other persisted object (i.e. a bean). Note that objects like DateTimes, RichTextStyles etc are children of the session, not of any more granular Domino object like a NotesItem or NotesRichTextItem.
var tmpVar = new package.TestClass() will only get persisted beyond the current request if you store tmpVar somewhere. If you're using that code in a crerateObject method, return tmpVar will pass that instance of TestClass into the Data Object.
I go back and forth on pure Managed Beans vs. Data Object. I was using a lot of Data Objects for a while but then ran into some issue with the JSF lifecycle I think that I just couldn't make work. Not sure if a repeat or custom control was involved. So I pretty much have gone back and given up on them for now.
Other then that problem I had I'm not sure there's a ton of difference. I think dataObject can tend to be a little more confusion. Since you can set it on an XPage - but you can change the scope of it to session or application I believe. But if you do then that seems messier and hard to find then making the bean in the faces-config.
I'm not sure about the saveObject part of your question.
You never want to put a pure domino object inside a bean, or scoped variable because they are not serializable and will be tossed by the garbage collector at some point that will likely be most inconvenient to you.
if you just do "var tmpVar = new package.TestClass()" then yeah that will get killed pretty quick because of limited life of that variable. if you want to create an object that way and keep it around longer put it in a true scope: viewScope.put("myObject", tmpVar);
I have a video where I tried to give examples of I think 4 ways to use java Objects. In the blog posting are some really good comments by Tim Tripcony which might give you further information.
http://www.notesin9.com/2013/08/01/notesin9-122-working-with-java-objects-in-xpages/
I've created a cutom BindingNavigator with custom ToolStripButton(s), basically working with datasets, in which I've coded delegate actions to perform when adding, deleting and updating records.
As I'm moving to EF5, I would like to make the same thing, the idea still the same, but when executing these three methods:
this.BindingSource.AddNew();
this.BindingSource.RemoveCurrent();
this.BindingSource.Update();
modifications are made in runtime but not in database.
I found later that i must execute
context.SaveChanges();
to make data concrete.
Can anyone help on how to call the context from the custom binding navigator class.
is there a simple and efficient/fast way to query a managedobjectcontext to get an array of all the managedobjects in the context that have not yet been added to the persistent store?
i ask this because i would like to be able to save nsmanagedobjects that have been added to the MOC only if they conform to certain criteria. basically i want to be able to do this so that if some unexpected event happened before my managed object attributes were properly populated, i can catch this fact and purge the object(s) before saving the context. given the complexity of the navigation possible in the app, i'd like to have a look at the data to be sure they are good before i save.
i suppose i could also do this with some kind of validation rule and a flag field that doesn't get set until i am sure the user has added all the data to the record, but i don't yet know how to implement this...
any help much appreciated.
The insertedObjects method of NSManagedObjectContext
returns the set of objects that have been inserted into the context but not yet saved in a persistent store.
I am wondering if there is any special way to take action when something happens in a core data entity.
Here what I mean in the present case. I have a file name stored as an attribute in a core data entity.
As the app is running, it can happen that the item with this file name is removed from core data.
In that case what I want to happen is that the file gets removed from the file system.
And this is my question:
Do I need to write my own code to perform this removal?
Or is there a way, that I could use, so a removal procedure would be fired automatically when the item is removed from core data?
In other words, is there a call back method like:
-(void) objectWillBeRemoved:((NSManagedObject*))object
or:
-(void) objectHasBeenRemoved:((NSManagedObject*))object
Thanks for any relevant tip.
Check out NSManagedObjectContextObjectsDidChangeNotification.
You can read about it in NSManagedObjectContext Class Reference.
NSManagedObject#willSave and NSManagedObject#didSave should do what you want. See apple documentation
It seems controllerDidChangeContent: is being called as soon as I create a new managed object in my context. The documentation seems to suggest this method is called only once you save: the context.
This "bug" if it is one, is causing my application to crash because as part of my table view cell, I need to load other managed objects that don't exist at the time of creating the main managed object.
Someone seems to have spotted this too, please check out the following link and I would love to hear your opinions on this: http://openradar.appspot.com/10207615
More information
Although the link I added to this post showcases an example using two NSManagedObjectContext, my application is using one context, but the controllerDidChangeContent: is being messaged none the less as soon as an object is created in the one and only context, and controllerDidChangeContent: is being called a second time when I save: this context. It is to my understanding that this method should only be messaged when the context is saved.
The solution is to avoid dealing with more than one managedObjectContext. If your cell needs to load other managed objects, it should still use the same managed object context as the main managed object.
I have yet to see a use case where it is absolutely unavoidable to use more than one managed object context referring to the same model active at the same time.