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.
Related
I am fairly new to ember. I have an existing Ember App and i need to implement a functionality in it. I have a Ember Object as below
`import Ember from 'ember'`
CallService = Ember.Object.extend
... other code here
_updateConnectedLeadId: (->
console.log "Do i get here??"
**pass the route action here**
).observes('some_other_here')
`export default CallService`
Unfortunately, i couldn't put the whole code here.
My route looks like
ApplicationRoute = Ember.Route.extend
actions:
showLead: ->
console.log data
console.log "did i get here?"
#transitionTo('dashboard')
`export default ApplicationRoute`
I tried using #send('showLead'), #sendAction('showLead') in my method but no luck.
My main intention is to make a transition once the console.log "Do i get here??" is displayed. I am not sure if i am on the right way here.
I also tried using #transitionTo('dashboard') and #transitionToRote('dashboard') directly but it throws me errors.
I have been stuck for a day on this now and i am clueless.
I'll be grateful for any guidance and help. Thanks
You have the problem that you are trying to trigger a route action or trigger a transition from within an Ember.Object, named call service. The code you create is unclear about where your custom object is being created; where the observer is triggered due to a change to object's property update, and so on.
Nevertheless, I tried to provide a working example for you. If you open the twiddle, you will see that I created a my-object instance within index.js route and pass it as model to my-component. When you click the button within my-component.hbs. The my-object instances dummyVariable is toggled and the observer within my-object executes. The tricky part here is that I passed index route itself as ownerRoute property to my-object instance; so that I can trigger the index route's dummyAction from within my-object.js with
ownerRoute.send('dummyAction');
so that related action executes and transition to my-route is performed. Although, I believe this might solve your question; I am not quite happy about the design. I do not think, it is a good way for Ember.Objects to know about routes, actions, controllers, etc. I believe the proper way is observing object's relevant properties from within this constructs and perform necessary actions by their own. Moreover, you might consider creating a service instead of an object and inject the service directly to your route instead of creating an instance of your class extending Ember.Object. If you have to extend from Ember.Object you can just inject relevant route, controller, etc to the instances of that particular object class by using an instance-initializer if you need.
Anyway, please take a look at the twiddle and ask more if you need to. I will be happy to help if I can.
I have a 'document' table (very original) that I need to dynamically subset at runtime so that my API consumers can't see data that isn't legal to view given some temporal constraints between the application/database. JOOQ created me a nice auto-gen Document class that represents this table.
Ideally, I'd like to create an anonymous subclass of Document that actually translates to
SELECT document.* FROM document, other_table
WHERE document.id = other_table.doc_id AND other_table.foo = 'bar'
Note that bar is dynamic at runtime hence the desire to extend it anonymously. I can extend the Document class anonymously and everything looks great to my API consumers, but I can't figure out how to actually restrict the data. accept() is final and toSQL doesn't seem to have any effect.
If this isn't possible and I need to extend CustomTable, what method do I override to provide my custom SQL? The JOOQ docs say to override accept(), but that method is marked final in TableImpl, which CustomTable extends from. This is on JOOQ 3.5.3.
Thanks,
Kyle
UPDATE
I built 3.5.4 from source after removing the "final" modifier on TableImpl.accept() and was able to do exactly what I wanted. Given that the docs imply I should be able to override accept perhaps it's just a simple matter of an erroneous final declaration.
Maybe you can implement one of the interfaces
TableLike (and delegate all methods to a JOOQ implementation instance) such as TableImpl (dynamic field using a HashMap to store the Fields?)
Implement the Field interface (and make it dynamic)
Anyway you will need to remind that there are different phases while JOOQ builds the query, binds values, executes it etc. You should probably avoid changing the "foo" Field when starting to build a query.
It's been a while since I worked with JOOQ. My team ended up building a customized JOOQ. Another (dirty) trick to hook into the JOOQ library was to use the same packages, as the protected identifier makes everything visible within the same package as well as to sub classes...
For every managed object that is sent via iCloud update, this warning/error is sent to the console:
*** ERROR: this process has called an NSArray-taking method, such as
initWithArray:, and passed in an NSSet object. This is being
worked-around for now, but will soon cause you grief.
My managed objects are Clients and have a one to many relationship with assessments as shown below.
class Client: NSManagedObject {
//other NSManaged vars are here
#NSManaged var assessment: NSOrderedSet
}
Judging by the timing of this error (during ubiquitous updates) and the fact that this is my only use of NSSet objects in my project, I can presume that a function during this update is being passed an NSOrderedSet when its expecting an NSArray.
Turning off iCloud removes the errors.
I found two other folks with a very similar issue:
Using iCloud enabled Core Data NSArray-taking method
Core Data Relation between Objects
However, neither offers any solution to my problem. Everything is working fine right now, however "it will soon cause you grief."
If this isn't resolved here, I'll take this issue up with the apple dev support.
I figured it out how to fix this error after much research. (No help in from the Apple Dev forums).
This is error is caused by the Swift 1.2 upgrade. They encourage you to use their new Set<> class instead of NSSet. The error was a vague way of reinforcing that claim.
Ordering of my data was ultimately handled by my NSFetchedResultsController, so I didn't need the stored data to be ordered. So I set out on a task to change the data type for my one to many relationship from NSOrderedSet to Set.
So I created a new data model, selected my relationship and unchecked "Ordered" in the data model inspector. Then migrated to the new model in the next run. (as shown below)
Once that was done, I changed the data type in my managed object subclass from NSOrderedSet to Set. (or Set). That generated compiler errors that were easy to fix throughout my code.
The new Set class easily converts to an array: Array(mySet)
To insert an object to the set, there's an easy insert method. foo.mySet.insert(objectToInsert).
Side note: Converting my relationship to a Set also fixed some weird ordering issues I was having with my table views and the NSFetchedResultsController.
Then I ran the program, generated data, uninstalled the program. Ran the program again and watch the glorious iCloud data populate without the annoying errors.
Boom. I hope this saves someone out there the 10 hours of turmoil (I tried a lot of different things..) I spent to fix this.
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.
This question covncerns my lack of understanding of how to use the core data undo manager and how to restore a NSManagedObject to its state before editing was done.
I am just learning my way around Core Data. I have my NSManagedObject classes set up with their dynamic accessors. I perform a fetch that returns several NSManagedObject entity results. Content from each of these entity results (first name, last name) get put into a table view, and then the user picks one out of the table for detailed view and then editing.
The detail view controller receives a pointer to the selected NSManagedObject entity. As the user edits the fields, the corresponding property value in the NSManagedObject entity is updated. This seemed like the cleanest way to manage these changes.
Now, rather than committing the changes using save, I want to provide a cancel-editing feature that rolls back to what is in the data base for that entity. I really only want to restore the one entity and not perform the entire refetch.
I tried rollback and I tried NSUndoManager (with beginUndoGrouping and endUndoGrouping), and that is not working. I don't think I understand what rollback is really supposed to do.
But in any case, I still want to restore the property values in just that single entity (taking the lazy approach to only fetch what is needed, which is the one entity) so that my detail view controller can refill its view with the correct information. Right now it is using the NSManagedObject entity values, which contain the edited values, which were cancelled.
I suppose I could just start the edit process by creating a copy of the NSManagedObject. If the cancel-editing button is pressed, I could copy it back into the original. (I might even be able to just replace the original with the copy by moving the pointer. But since the pointer has actually been passed through several objects, I'm not sure how to manage the retain number on the copy.)
Does anyone have any other suggestions?
Thanks
Using rollback should accomplish what you want and I'm not sure what it doesn't. It is probably an implementation detail error.
You can find the specific managed object/s that were updated but not yet saved by calling the context's updatedObjects.