I want to programmatically (without Lightweight Migration) create a mapping model between two models that are exactly the same, except one of the entities (there are a bunch of entities) has different attributes. Let's call this entity "Person". And let's say the destination model has
1) added a new attribute called "address"
2) deleted an attribute called "eyeColor"
3) kept (i.e. not done anything with) an attribute called "name"
How would you create an NSMappingModel between these models programmatically? I happen to have some explicit questions that might help me do this by myself:
Q1) Do I have to create NSEntityMapping objects for all of the entities other than "Person", even if they remain unchanged?
Q2) How do I deal with the "address" attribute in "Person", which is a new one being created? Should I create an NSPropertyMapping for that somehow, that turns nothing into something ("address")?
Q3) How do I deal with the "name" attribute in "Person"? Do I have to create an NSPropertyMapping for that, even though it simply stays the same?
Q4) For the NSEntityMapping corresponding to "Person", is not creating any NSPropertyMapping for "eyeColor" a proper way to get it deleted? Or should I create an NSPropertyMapping for "eyeColor"? If yes, how would this object be created, i.e. what would determine that its purpose is to get rid of "eyeColor"?
Thank you in advance, and I apologize not being able to answer these questions myself, as the documenation really has no good example of how to create NSMappingModels programmatically. Note again that I'm not allowed to use Lightweight Migration. I must do this manually.
I've always used the automatic mapping feature of Xcode but it seems to me you can learn a lot from that as well. Make a model of (parts of) the source model, add a version, modify it to reflect the destination model and generate a Mapping Model (menu Design >> Mapping Model). If you then control-click the .xcmappingmodel Xcode has generated for you and tell the Finder to show you the contents of the package, you'll find an XML file inside that lists all the mappings. You can use the xml as a guide to help you recreate the process in code. Good luck.
Related
When I go to Editor-->CreateNSManagedObjectSubclass, and export my entities, they show up as the entity names... but another person who was working on my project before seems to have exported as their name with an underscorebefore, and these files look totally different on the inside...So I'm confused as to what's going on. Here's a google doc that contains a few relevant screenshots... Check out the second page to the two sections of fields. I'm sort of confused by them:
https://docs.google.com/document/d/1BMBqJME91Njb69JS4x3bvH0-KSmC-KLBl6QglE22jmQ/edit?usp=sharing
Can someone explain what is going on here?
You might want to read up on MOGenerator, since that's apparently what your predecessor used to generate the managed object classes. By default MOGenerator generates base classes prefixed with an underscore and initially generates stub subclasses (the ones without the underscores).
You can then write any custom code in the subclasses. That way, whenever the model changes, you can regenerate the base classes without worrying about clobbering your custom code, since by default MOGenerator won't regenerate the subclasses.
In summary, I'm trying to create instance-specific data-annotation attributes at runtime, based on database fields. What I have now works fine for creating the initial model, but falls over when the model is posted-back and the server-validation happens.
(I have the same input model being used in a collection within a viewmodel, but different validation must be applied to each instance in the collection....for example the first occurrence of the input may be restricted to a range of 1-100 but the next occurrence of the same model, prompted for on the same input page, would be a range of 1000-2000. Another may be a date, or a string that has to be 6 characters long.......)
I'll explain what I've done and where my issues are:
I've inherited DataAnnotationsModelMetadataProvider and provided my own implementation of GetMetadataForProperty (This doesn't have any bearing on the validation problem....yet)
I've inherited DataAnnotationsModelValidatorProvider and provided a facade implementation of GetValidators. What I want to do here is create new attributes based on my database-records and then pass those attributes through to the base implementation so the Validators are created accordingly.
However...... GetValidators is called at a PROPERTY level....When it is called with a propertyname that I want to apply validators to, I need to find the applicable DB record for this propertyname so I can find out what attributes I need to create....BUT...I can't get the DB record's key from just a propertyname of the value field.....In fact, the DB key is in the parent model.....So how do I get hold of it?!
I've tried using a static variable (YUK) and storing the key during a call for one property, and retrieving it during another call for my value field property....But because the model is serialised one-way and deserialised the opposite way I end up with my key being out-of-sync with my required attributes.
To add a slight complication I'm also using a custom model binder. I've overridden CreateModel as advised elsewhere on here, but I can't find a way of attaching metadata or additionalvalues to a PROPERTY of my output model....Only to the model itself....but how do I get at MODEL metadata/additionalvalues inside the GetValidators call for a PROPERTY ?
So....My question is twofold.....
1) Can anyone help me get my database-key from my custom-Model-binder to my GetValidators method on my ValidationProvider? Or maybe using my custom Metadata provider?
2) Is there a different, simpler, way of creating validators at runtime based on database records?
I think you are making this far more complicated than it needs to be. You just need to make whatever your validation criteria selectors are part of your view model. They don't necessarily have to be displayed (they can be stored in hiddens if they need to be kept for postback purposes).
Then you can use something like FluentValidation to create rules that say
RuleFor(model => model.myprop)
.When(model => model.criteria == whatever)
.GreaterThan(100)
.LessThan(1000);
Where criteria is whatever value you use to select when your property has to be in a certain range.
So that would mean you build your view model to include the criteria that is used for validation rule selection.
I'd asked this on the FluentValidation forums also and the lack of answers here as well as the advice against using Fluent from there led me to find my own solution (I understand this almost certainly means I'm doing something really bad / unusual / unnecessary!)
What I've ended up doing is assigning my controller static variable in my Custom Model Binder's CreateModel method, where I have access to the entire client model, rather than trying to do it through a custom MetaDataProvider. This seems to work just fine and gets me towards v1 of my app.
I'm not really happy with this solution though so will look to refactor this whole area in the coming months so would still appreciate any other comments / ideas people have about how to implement dynamic validation in a generic way.
I know this is an old question, but I am answering this so that many others can be benefited from this.
Please see the below article where they are loading the attributes from an xml
Loading C# MVC .NET Data Annotation Attributes From XML, Form Validation
I think you can follow the same approach and instead of reading from xml you can read from database and add these rules dynamically based on the model data type
You can refer the below approach also
DataAnnotations dynamically attaching attributes
Our current application uses a smart object style for working with the database. We are looking at the feasibility of moving to PetaPoco instead. Looking over the features I notice you can add attributes to make it easier to CRUD objects. Does adding these attributes have any negative side effects that I should be aware of?
Has anyone found a reason NOT to use these decorators?
Directly to the use of the POCO object instance itself? None.
At least not that I would be aware of. Jon Skeet should be able to provide more info because he knows compiler inner workings through and through, so he knows exactly what happens with this metadata after it's been compiled.
Other implications indirectly related to these
There are of course implications when accessing these declarative attributes, because they're read using reflection which is normally a slow process.
But there's nothing to worry here, because PetaPoco is a smart library and reads these only once then compiles & caches these things, so you only get penalized once then you get blazing performance afterwards. Because it uses compiled code.
Non-performance related implications
By putting attributes (any) on your classes/properties/methods you somehow bind your code to particular engine that will use this class, because they're directives for this particular engine to understand your code.
In case of PetaPoco attributes this means that your class can be used with PetaPoco but not with some other DAL (ie. EF) unless you add attributes of that one as well (EF Code First uses the very same approach with attributes).
The second implication is related to back-end database. In case you rename a table, column or any other part that is provided in your PetaPoco attribute as a constant magic string, you will subsequently have to change this string as well. This just means that you have to be thorough when doing database changes...
One downside is that it breaks the separation between the "domain" layer and the "data" layer, since it introduces the PetaPoco file (which contains data logic) to domain classes that should really not have any knowledge or dependency on the data layer.
If you're doing a single-project MVC app or something then it's okay to just use the Models directory for both, but for non-trivial and separated apps you'll have to have two PetaPoco files or play around with abstracting portions of the file in order to annotate your models without making them "know too much" about the underlying data, or else have you specify the table and/or primary key name all over the place.
I have changed a relationship on an entity to be a different managed object type in a new version of the data model. Rather than convert the old managed object types into the new managed object types is there a way to tell the mapping model between the two versions to delete all objects that were previously in this relationship?
If not, perhaps there is a much easier and simpler way to do this?
I find that if I delete all of the .h/.m files that correspond to the entities and then go back in and ask Xcode to make new ones (File>New>New File>Core Data>NSManagedObject subclass then the new .h/.m files that are created are the updated ones from my model. I am not sure if you want to risk just deleting them all.
I hope I understood your question, and I hope this helps
I'm considering using Core Data for an app I'm writing. However, after reading the docs I'm unsure how to model a particular relationship. Here's the basics:
I have an Entity called "ProjectFile" that has some basic string properties. (One of those is a path to a file on disk -- call it "File X" -- that my app is going to manipulate.) However, when the app manipulates file X, it may also need to manipulate OTHER files --- fileY and fileZ.
FileY and FileZ, like fileX, will be "ProjectFile" entities. So I need a way to tell Core Data "FileY and FileZ are associated with FileX." To do that, I created a relationship on the "ProjectFile" entity called "linkedFiles" and set the destination to "ProjectFile" and the inverse to "linkedFiles". I then set this as a "to-many" relationship, as each "ProjectFile" may have multiple linked files.
This seems recursive to me and I'm not sure I've done it correctly. The "linked" files (fileY and fileZ) need to exist on their own, just as fileX does. I need to be able to "delete" them from the "linkedFiles" relationship but still have them exist separately, if that makes sense. Essentially, I just need a weak relationship between separate objects in my model.
Have I done this correctly, or am I missing something? Thanks!
So, you have a data model that looks something like this:
ProjectFile{
path:string
infile<<-->>ProjectFile.infile
}
This will work because (1) Core Data relationships have directionality/cardinality and (2) each object is unique. Where you can get into trouble is with delete rules. You pretty much have to use No Action or Nullify in this circumstance or risk setting off a cascade delete. That in turn runs the risk creating orphaned objects that have no relationships and are hard to find and remove in the object graph.
A better model would encode more information in the relationships themselves. It appears that the real-world file objects you are modeling have two separate relationships to other file objects: (1) Each instance has other instances that it manipulates and (2) each instance has other instances that manipulate it. So, your model should reflect that:
ProjectFile{
path:string
toManipulateFiles<<-(nullify)->>ProjectFile.manipulatedByFiles
manipulatedByFiles<<-(nullify)->>ProjectFile.toManipulateFiles
}
This makes explicit the type relationship between the objects and lets you quickly and easily get the right objects for any particular operation. You can use Nullify on one relationship without orphaning the object on the other.
Although it isn't immediately obvious, relationships aren't just lines on a graphical model, they are actual live objects that can carry a lot of information. You need to design with this in mind.