I have been struggling to get fetched properties working correctly in my app and have been finding it extremely confusing - mainly due to this strange issue I have finally figured out!
Basically if I change the Predicate on a Fetched Property in my xcdatamodeld and then Build-Run the app ignores this new Predicate and continue to used the old Predicate.
Hard to describe how absolutely annoying and frustrating this is, but am sure I am not the first to encounter this.
Any idea's on how I can force this to update the changes with each rebuild?
Ok so according to Apple's Core Data versioning guidelines, two versions are treated as being identifical if:
For each entity the following attributes must be equal: name, parent, isAbstract, and properties. className, userInfo, and validation predicates are not compared.
For each property in each entity, the following attributes must be equal: name, isOptional, isTransient, isReadOnly, for attributes attributeType, and for relationships destinationEntity, minCount, maxCount, deleteRule, and inverseRelationship.
So looks like changing a fetched property's predicate doesn't qualify as a 'change' ... how wonderfully confusing.
You can force it to consider the model 'changed' by changing the value of the Core Data Model Identifier
Related
So as a project matures it will almost certainly be necessary to modify attributes of the resource definitions to cope with additional requirements.
Let's use two trivial examples - to add a country code to a client address, or to remove a middle initial and swap in a middle name field instead.
Currently if the resource definition changes, composer won't read whatever values are extant in the repository. I didn't exhaustively try all combos, but have had to reconstitute my blockchain at least twice because of this problem.
Is there a way to mark fields either as "new" or "deprecated" to get past this that I overlooked? It will be hard to make a case to move a system that can't be changed forward to production.
In the same vein it doesn't seem to like empty or null strings much (at least for participant attributes). Having an "optional" override somewhere would save a lot of extra bounds checking in my application. Is there one of those I missed too?
So you can use the APIs or REST to expose the legacy data? You may be referring to Playground above (its not really a tool for looking at production data, its for model prototyping/sandbox/testing type stuff).
On optional question - can just add that the field is optional in the model - example here -> https://github.com/hyperledger/composer-sample-networks/blob/master/packages/pii-network/models/pii.cto#L20
I'm deleting an instance of an entity and depending on the value of an option set in it, I wish to carry our different course of action. The problem is that the field isn't changed, hence, not provided to the plugin's target.
How can I easily tell the stupid plugin to fetch all the fields?
The way I do it now is to use pre-image but I'll be showing the plugin to some rookies and they will definitely not like it. And they won't believe me that's the way to go, for sure, because they're a cocky bunch.
Is there a work-around for that?
Using the pre-image is the suggested way in this scenario, the alternative is to instantiate a service factory in order to get an IOrganizationService and retrieve the entity using the target's Id.
It is part of the IPluginExecutionContext (of which Target is one part.) I think the beginners are confused if they think of Target as anything more than a property of IPluginExecutionContext.
It wouldn't make sense to have these values as part of Target, because then it would cause an update of the field to its current value - if you forced it into Target you would see the update in the audit details.
Thus, CRM has PreEntityImages, Target, and PostEntityImages, if Target was used the way "they" want it would not be able to differentiate between values being updated, previous values, and the final result of the entity.
This question may have already been asked, sorry
I'm looking at the architecture for validating our model. Our simple validation can be achieved by using the property validation attributes (some custom) and using
ModelState.IsValid
however the problem is when validation requires access to the database or access to another property. A perfect example is to check for duplicate names. In this case we need to check the database for duplicate names where the id is not equal to that of the current object (for updates)
If we were to write this as an validation attribute to be applied to the name property this would cause to problems. Ome how do we get access to the database and two how would we get access to the id property.
So in conclusion. Is there any examples of good ways to architect a fix to this problem?
I spent some time exploring this today for a project I was working on and came to these conclusions.
It is not to bad to solve the how, much of it involves some reflection and using the validation context to inspect and access other properties of your model or using IValidationObject. The real question becomes is it okay to do validation that requires database interaction.
For one I was concerned about performance, in one particular case a validation made a query that returned an object to ensure it existed which I later needed for relationship assignment which would then cause another query.
Secondly you need to think about database concurrency. The best way to do duplication checks is during insert not before because the database could change between the two operations. This also relates to the first reason, an object could be deleted immediately after a database reported it exists.
In my particular project I felt it better to keep this sort of behavior with modifying my EF context and adding anything that went wrong to the ModelState.
I search with reflector and I didn't manage to find a case where the ValidationResult.MemberNames is supposed to contain more than one value.
So, first of all I am wondering why MS had to do it IEnumerable<string>, then now that they already did this, can I rely that this property will only return one value?
Update
Concerning the DataAnnotations validation system I find more sloppiness:
The TryValidateProperty and TryValidateObject should have removed the errors from the validationResults parameter if they don't exist any more.
ValidationResult should have overriden Equals and GetHashCode.
Why is the ValidationResult.ErrorMessage mutable!? I can't event build an EqualityComparer myself!
If the DataTypeAttribute is only used for representation concerns, why does it inherit ValidationAttribute, that's just misleading, I had to struggle till I understood (after reflectoring) that its not going to work. MS just didn't implement it.
And the list goes on.
Consider Password and PasswordConfirmation. Or any Start/Stop values, or any other cross-field validation.
My document-based Cocoa application uses a NSOutlineView/NSTreeController combo, bound to the document's Core Data store. My NSTreeController has the fetch predicate isRoot == YES. isRoot is a transient boolean attribute with a default value of NO. My root model's awakeFromInsert calls:
[self setIsRoot:[NSNumber numberWithBool:YES]];
I'm able to add objects to the hierarchy just fine, but when I try to load a document I just saved, I get an exception:
[<NSDictionaryMapNode 0x1001a8190> valueForUndefinedKey:]: this class is not key value coding-compliant for the key isRoot.
I can work around this exception and successfully load a newly-saved document if I change the isRoot attribute to non-transient in the xcdatamodel, but based on my understanding of the transient flag it should not cause a problem, and this really isn't the kind of data that should be persisted.
I have also tried implementing -isRoot in the NSManagedObject subclasses to return the appropriate fixed value, as well as making the same setIsRoot: call within awakeFromFetch, both to no avail.
Is there some other subtlety I'm missing? I can't imagine that fetch predicates don't support transient attributes. I don't know much about the inner workings of Core Data but it seems interesting that it's trying to look up isRoot on the store-specific class and not my NSManagedObject subclass.
I can't imagine that fetch predicates
don't support transient attributes.
After a bit of research, I can tell you that they don't. See this document. Quote:
You cannot fetch using a predicate
based on transient properties
(although you can use transient
properties to filter in memory
yourself).
I've put together a test project and can verify I get exactly the same error as you do.
When I need to filter out the root nodes in a tree, I use a fetch predicate of parent == nil instead of a transient attribute.
I understand your reaction - I too wanted way of having an attribute specifically called isRoot too. My guess is it's possible, but it'd take so much code it's just not worth the hassle.
Oh, and if you're dealing with core data any more than a little, mogenerator will make your life much easier.
Another option is to have a separate class for the top-level nodes, use that class name as "Entity Name" and leave "Fetch Predicate" blank. As long as the child nodes have the same values as the top-level node (I use a common superclass/entity inheritance), everything still works.
Have you made sure that the NSTreeController is set to control an entity rather than a class?
From your error, it looks like it might be set to a class with the default - NSMutableDictionary.
I'd also argue that maybe isRoot could be persisted. It depends on what you're trying to do with your app, of course, but if it's a tree view that gets loaded on app run I'd either make isRoot persist.