I'm currently wrapping my head around some problem with Core Data.
I have one user model in its own store that I do not have any control over, as it gets shipped with a framework. A Persistent Store Coordinator, Managed Object Model and Context for this model gets created automatically and cannot be touched. In it, this model has a single user entity
On the other hand, I have a properties model with a properties entity in it that I have complete control over. In there I store properties for some user entities in the other store. Both user and property entities have an id attribute similar to a foreign key.
This model has it's own Persistent Store Cordinator, Managed Object Model and Context.
What I now want is to have the associated user entity as an attribute of the properties entity so I might be able to bind to key-paths similar to myproperty.user.someValueOfTheUserEntity (I'm aware that myproperty might be an array when using fetched properties).
However, as cross-store relationships are not supported I thought of using a weak relationship via Fetched Properties. That one would just have to match the two corresponding id attributes. I have created a Fetched Property for the user in Xcode and the required accessors in my properties entity's class file (As suggested in other questions, I'm treating the values returned by the Fetched Property as an array).
However, I'm unable to set a destination entity for the Fetched Property in Xcode, as the target entity resides in a completely different store. Would I also have to define my user entity in the properties store? If so, how does Core Data know that that entity shall be fetched not from my properties store but from the users store?
Some threads mentioned using configurations for this, but I cannot find any documentation that goes further than mentioning "use configurations for this".
Can somebody enlighten me on how to set up cross-storage fetched properties? #
You can use several persistent stores that share the same data model:
Use single data model (xcdatamodeld) and add all your entities
Create configurations (Editor/Add Configuration) for each "logical set" of
entities that should be stored in separate store file
Assign (Drag) entities to appropriate configurations
Add configured persistent stores to your context (see below)
Configure fetched properties
// 1. Add "static", read-only store
[coordinator addPersistentStoreWithType:NSSQLiteStoreType
configuration:#"your static configuration name goes here..."
URL:storeUrl
options:#{
NSReadOnlyPersistentStoreOption: #(YES),
NSInferMappingModelAutomaticallyOption : #(YES)
}
error:&error];
// 2. Add "dynamic", writable content
[coordinator addPersistentStoreWithType:NSSQLiteStoreType
configuration:#"your dynamic configuration name goes here..."
URL:storeUrl
options:#{
NSMigratePersistentStoresAutomaticallyOption: #(YES),
NSInferMappingModelAutomaticallyOption : #(YES)
}
error:&error];
Related
I'm developing a RESTful webservice with spring-data as its data access layer, backed by JPA/Hibernate.
It is very common to have relationships between domain entities. For example, imagine an entity Product which has a Category entity.
Now, when the client POSTs a Product representation to a JAX-RS method. That method is annotated with #Transactional to wrap every repository operation in a transaction. Of course, the client only sends the id of an already existing Category, not the whole representation, just a reference (the foreign key).
In that method, if I do this:
entity = repository.save(entity);
the variable entity now has a Category with only the id field set. This didn't surprise me. I wasn't expecting a save (SQL insert) to retrieve information on related objects. But I need the whole Product object and related entities to be able to return to the user.
Then I did this:
entity = repository.save(entity);
entity = repository.findOne(entity.getId());
that is, retrieve the object after persisting it, within the same transaction/session.
To my surprise, the variable entity didn't change anything. Actually, the database didn't even get a single select query.
This is related with Hibernate's cache. For some reason, when in the same transaction, a find does not retrieve the whole object graph if that object was previously persisted.
With Hibernate, the solution appears to be to use session.refresh(entity) (see this and this). Makes sense.
But how can I achieve this with spring data?
I would like to avoid to create repetitive custom repositories. I think that this functionality should be a part of spring data itslef (Some people already reported this in spring data's forum: thread1, thread2).
tl;dr
References between entities in the web layer need to be made explicit by using links and should not be hidden behind semi-populated object instances. References in the persistence layer are represented by object references. So there should be a dedicated step transforming one (the link) into the other (the fully populated object reference).
Details
It's an anti-pattern to hand around backend ids as such and assume the marshaling binding doing the right thing. So the clients should rather work with links and hand those to the server to indicate they want to establish a connection between an already existing resource and one about to be created.
So assuming you have the existing Category exposed via /categories/4711, you could post to your server:
POST /products
{ links : [ { rel : "category", href : "/categories/4711" } ],
// further product data
}
The server would the instantiate a new Product instance, populate it with additional data and eventually populate the associations as follows:
Identify properties to be populated by looking up the link relation types (e.g. the category property here.
Extract the backend identifier from the given URI
Use the according repository to lookup the related entity instance
Set it on the root entity
So in your example boiling down to:
Product product = new Product();
// populate primitive properties
product.setCategory(categoryRepository.findOne(4711));
productRepository.save(product);
Simply posting something like this to the server:
POST /products
{ category : {
id : 1, … },
…
}
is suboptimal for a lot of reasons:
You want the persistence provider to implicitly persist a Product instance and at the same time 'recognize' that the Category instance referred to (actually consisting of an id only) is not meant to be persisted but updated with the data of the already existing Category? That's quite a bit of magic I'd argue.
You essentially impose the data structure you use to POST to the server to the persistence layer by expecting it to transparently deal with the way you decided to do POSTs. That's not a responsibility of the persistence layer but the web layer. The whole purpose of a web layer is to mitigate between the characteristics of an HTTP based protocol using representations and links to a backend service.
I have two tables that exist in the same Oracle database system but different schemas, which I've mapped like this:
ABC.Store:
component schema="ABC" table="Stores"
{
property name="Id" fieldtype="id" generator="sequence" sequence="store_id_seq";
property name="Products" fieldtype="one-to-many" cfc="Product";
}
DEF.Product:
component schema="DEF" table="Products"
{
property name="Id" fieldtype="id" generator="sequence" sequence="product_id_seq";
}
I set my application's default datasource as this.datasource = "ABC" in application.cfc.
The problem I'm running into here is whenever I try to save a Product. ColdFusion spits out an error that says the sequence cannot be found for the Id property on Product. This is because the product_id_seq sequence is in the DEF schema, but ColdFusion is trying to find it in the ABC schema, even though I set the schema on the Product as DEF.
If I set the datasource attribute on Product to DEF, I then get an error that says the Products property on Store is unmapped. This is because, as the ColdFusion documentation states:
"Since a Hibernate configuration uses a single data source, all related CFCs (using ORM relationships) must have the same data source."
My question then is, how do I map the two tables in two different schemas, using a sequence as an ID generator?
I've been able to get it to work if I specify the schema for the sequence:
property name="Id" fieldtype="id" generator="sequence" sequence="def.product_id_seq";
But this is hard-coded and I'd like it to be dynamic and pull the schema name from a configuration bean.
The only way I've been able to get this to work seamlessly was to:
Create a single user in database, in this case MySQL, that had access to the desired schemas.
Setup and configure a single datasource in CFIDE that utilizes the newly created user for authentication.
Set the datasource attribute in all desired persistent objects to the newly created datasource.
Set the schema attribute in all desired persistent objects to reference the correct schema, or database. (the two are synonymous in ColdFusion ORM)
Note: Be sure to use full component path when referencing CFCs in your COM.
The steps I go through...
Add new ADO.NET Entity Data Model > Generate from DB > Setup new connection string to adventureworks db > Next > Select table "DatabaseLog" > Finish. Verify DatabaseLog is visible in the edmx view.
Right click controller > Add controller
TemplateController with read/write actions and views, using Entity
Model class
AdventureWorksDWEntities
Context
New data Context > Accept default name
View
Razor
Click Add.
Produce Error:
"Unable to retrieve metadata for 'DatabaseDocumentor.models.AdventureWorksDWEntities'.
System.Data.Edm.EdmEntityeType: EntityType 'AdventureWorksDWEntities' has no key defined. Define the key for this entitytype.
System.Data.Edm.EdmEntitySet: EntityType: EntitySet 'AdventureWorksDWEntities' is based on type 'AdventureWorksDWEntities' that has no keys defined.
I tried again using AdventureWorks (not AdventureWorksDW) and this time it worked. But, I still don't understand what to pick when generating a controller. I have 3 options:
Template
Here I picked Controller with read/write actions and views, using Entity. This is easy enough to understand. I want to have my tables generated for me so I pick this option.
Model
This is what I want to model. In this case I want to model the "Department" table. So I choose Department.
Context
This one is real fuzzy to me. I chose *Name*Entities. This is the value in the web.config connection strings area. Why do I need to choose my connection string as the context? I only know context as "an object that I use to get to my entities" in C#. So, here it's hard for me to visualize. Do I need to always choose my connection string for the context?
This issue can occur when the Context is not correctly chosen from the dropdown. The context should be the value stored in the web.config
<add name="NamedEntitiesCs1"
that also contains the Model you want to generate.
I found what the issue is...
I have a 3 tiered architiecture I'm using with each of the below projects in one solution.
1.YeagerTech
2.YeagerTechWcfService
3.YeagerTechModel
No matter what, even though my wcf service references my model, the startup project (1) is not "smart" enough to recognize the metadata to create the Controller. In this case, you must include a reference to your project that includes your edmx model.
You must also ensure that the connectionstring also resides in the startup project (1) via the web.config file, in order to get the connection for the metadata.
I found the answer, the model class should have a key, that is an ID property i.e
public int ID { get; set;}
save the changes and the build or rebuild the solution.
That should be able to work out.
your property in your Model for the ID must be declared as public. rebuild and try again, it should work
I have a set of data created by another app and stored in XML format on disk. Since this data is managed by this other app, I don't want to bother with loading this data into a Core Data store for two reasons: 1) it would be redundant storage of the same data, and 2) I would have to constantly update my own Core Data store to match updates in the XML file produced by the other app.
However, I have data created in my own app that needs to be associated with the data from the XML from the other app, and I want to save the data created in my own app to disk.
To accomplish this, the XML data from the other app has persistent, unique IDs associated with each object stored in the XML file. I store these unique IDs in my own Core Data store. Upon every launch of my app, I load the XML data created by the other app, and then I can access the corresponding data in my own app via Core Data by issuing a fetch request for managed objects matching the unique ID.
OtherAppObjects represents items loaded from the XML data. They have their own unique properties in addition to the uniqueID. These OtherAppObjects are controlled by an NSArrayController. Then I have MyManagedObjects which are loaded from the Core Data store, and have distinct unique properties in addition to a uniqueID.
I have a table view which needs to display properties from both the OtherAppObjects as well as the MyManagedObjects, so I want to be able to access and set properties of the MyManagedObjects via bindings from the OtherAppObjects. Thus, I figured that I could create a correspondingMyManagedObject property of the OtherAppObjects, and then I'd be able to access the Core Data properties of the MyManagedObject via bindings.
For example, if I wanted to display property "foo" of the OtherAppObjects, and "bar" of the MyManagedObjects in the table view, I could simply bind one table column to the NSArrayController with a model key path of "foo", and bind the second table column to the model key path of "correspondingMyManagedObject.bar".
This works when not dealing with multiple threads, or when passing around a single managed object context. But since that's "strongly discouraged", I wanted to try to do this the right way by passing around a single persistent store coordinator, but creating separate managed object contexts.
However, this breaks down. The problem is that when the table view attempts to access the bar property, it needs to first access the correspondingMyManagedObject property. So, the OtherAppObject dutifully creates a new managed object context and a corresponding fetch request with the appropriate uniqueID and returns the managed object. But in doing so, it releases the managed object context and now the managed object is no longer valid, so the table view can't access the bar property!
I see only two ways around this, and I wanted to verify that there isn't another easier way to do this:
Load the objects from the XML data into my own Core Data store. In essence, create ManagedOtherAppObjects from the OtherAppObjects, with a relationship to the MyManagedObjects, and then accessing via bindings will be peachy. However, this means there's redundant storage of the same data on disk, and I'll have to recreate the ManagedOtherAppObjects every single time I launch the app (because the XML file is updated fairly frequently).
Create custom setters/getters on the OtherAppObject class. So, for example, I'd create -(NSValue *)bar and -(void)setBar:(NSValue *)newValue methods in OtherAppObject. Then, instead of binding the table view column to the key value path "correspondingMyManagedObject.bar" of OtherAppObjects, I'd just bind it to the key path "bar" of OtherAppObjects. These methods would be able to fetch the corresponding MyManagedObject and retrieve or set the value within the managed object context, and then return the correct value.
This second method isn't particularly appealing because I'd have to create two custom methods for every single property of MyManagedObject (and for properties of other managed objects for which MyManagedObject has a relationship).
I suppose I could create the generalized methods -(NSValue *)retrieveCoreDataPropertyUsingKeyPath:(NSString *)keyPath and -(void)setCoreDataProperty:(NSValue *)newValue usingKeyPath:(NSString *)keyPath , but I'd still have to create shell setters/getters for each individual property.
[UPDATE: Hmm, maybe I could just override valueForKeyPath: and setValue:forKeyPath:, and then everything would work OK?]
Is this correct, or am I missing something?
One variation on option #1 that could be worth a try would be to set things up so that you have a single persistent store coordinator that splits the objects between two separate persistent stores. You would keep MyManagedObjects (MMO) the same, being stored separately on disk, but then the OtherAppObjects (OAO) could either be backed by some temporary store on disk (e.g. in ~/Library/Caches or something) or just by an in-memory store.
Upon launch, you would create your PSC and add the store containing the MMOs. You would then add a second store to the PSC (using -[NSPersistentStoreCoordinator addPersistentStoreWithType:configuration:URL:options:error:]), read in the XML file and create all the OAOs, and associate those objects with that store using -[NSManagedObjectContext assignObject:toPersistentStore:].
Core Data doesn't allow directly modeling relationships between objects in different stores, but you could still do the lookup via unique ID like you're doing now to associate a MMO with an OAO. The difference would be that the OAO could simply use its own managed object context to fetch the MMO, so you would be sure that the MMO would stick around at least as long as the OAO.
Then, when you quit the app, you'd either delete the temporary store in ~/Library/Caches, or if using an in-memory store, just let it disappear into the ether, leaving the other store with the MMOs intact.
Do I need to save newly created CRM-entity instances before I can set relations to other crm entity instances?
I'm facing the problem that after calling CrmDataContext.SaveChanges() the newly created entities are written to the database, but the relations between those newly created instances are missing in the database.
What do I miss? Do I have to call CrmDataContext.SaveChanges() each time I create a new crm entity instance that I want to have relations to other CRM-entity instances?
You should be able to set relationships to other entities in a 1:N relationship before saving this entity(i.e. a lookup).
If you are wanting your entity to be referenced by another entity it will need to be Saved first OR you need to set a Guid for the entity first. Otherwise your link won't stick.
When you new up an entity its id is not set until it is saved to the database, unless you set it manually. If you set it manually it will respect the new Guid you have given it and the relationship will survive the saving process.
If you try to save an entity individually, you need to make sure that you have saved all the entities that it refers to before you save that entity, or it won't have a link.