Is it possible to create a fixtures yml file for a certain model from the data already stored in the database (e.g. like dump-data CLI but with specifying which data)?
When loading fixtures, you explicitly declare the models in the fixture file so this is the only way to do it, as far as I know.
If you're referring to loading fixtures into a database with existing data, loading fixtures for a specific model should not affect data in other tables, as long as you don't re-build the models. I haven't tested this though, so please do try it out in a safe environment first.
Another thing to bear in mind is that the data you upload as fixtures need to respect any foreign-key constraints you may have in your database.
Related
In Laravel we have the concept of seeding data that is used in conjunction with model factories in order to populate data for testing environment.
How should we proceed (where to put the code) when we need to populate data for production? For example I might have a permission table, and I need to add some default permissions along with the schema creation. After a while I might need to add to my app a new permission. Should these data insertion stay together with the migrations?
What mechanism should we use for inserting data? Models or data array? My problem with data array is that no business from models, will be helpful: like: casts or relationships.
I know, that there two discussions about this subject, but for me the solutions do no cover all the problems:
Laravel : Migrations & Seeding for production data
Laravel DB Seeds - Test Data v Sample Data
How should we proceed (where to put the code) when we need to populate data for production?
Our team makes a brand new migration for inserting production seeds (separate from the migration that creates the table). That way, if you need to add more seeds to your production data in the future, you can simply make a new standalone migration.
For example, your first migration could be 2016_03_05_213904_create_permissions_table.php, followed by your production seeds: 2016_03_05_214014_seed_permissions_table.php.
You could put this data in the same migration as your table creation, but in my opinion, the migration becomes less readable and arguably violates SRP. If you needed to add more seeds in the future, you would have two different "standards" (one group of seeds in your original migration, and another in a separate migration).
To answer your second question:
What mechanism should we use for inserting data?
I would always use your model's create() method for inserting production seeds. This ensures that any event listeners that are listening for your model's creation event properly fire. As you said, there could be extra code that needs to fire when your model is created.
I've made a small change to my database (just added a new entity to my model) and created a lightweight mapping model to handle the migration.
The migration still seems to be quite slow, looking at the log of the migration, it seems all SQL Lite tables are created again and all data migrated.
So, this is how Core Data works? I can't have a faster migration?
ps. I've a complex model, with 30 entities, and many relationships. They are not inheriting from the same parent entity. Maybe core data is not designed to handle such complexity?
Migration is a relatively rare event. It can take a while, especially for large, complex models with lots of data.
I am not entirely sure that new tables are created, but I think that this is indeed happening. It is how I would implement the migration if Core Data did not do it for me.
Here are some suggestions for improvement:
Make sure the migration occurs in the background. Inform your user and keep the app responsive as much as possible.
Perhaps something went wrong when you "created a lightweight mapping model". If you are doing not more than a certain subset of changes (see the docs), "Lightweight Migration" does not require you to create a mapping model.
I have a couple of questions about core data model migration.
I have a pretty complex data model with a couple cases of entity inheritance. I was going to make some changes to the data model in a new version and try and setup migration but when it migrated the store I lost some of the data that belonged to an entity that inherited from another entity.
In my case I have a few entities that all inherit from a "Resource" entity. This resource entity has a attribute "name". When I try to migrate the data store all entities that inherit from the "Resource" entity lose their name.
Is their any way to get model migration working for a data model with inheritance? I have already shipped a beta and I need to make a couple of updates to the model but I obviously don't want the users to lose all of their data.
Thanks
Try "playing" on your new model with Column properties > Versioning > Renaming identier, entering the previous field name, which I guess is the same. I doubt that will work with inheritance, but that is worth the try... (That not so documented feature, allowing to keep data across renames, saved me several times).
If that doesn't work, I'm afraid you have to do a "manual migration"... with Model mappings and other things... which is imho a bit complex. See Apple documentation on this topic... I then would suggest to just rollback your changes and forget inheritance, quicker & easier, even if it is less "clean". Or just assume your users will loose some data, at beta stage this is not so important... (Or maybe you can just collect old data in memory/plist file before migrating model an then repopulate)
Good luck! CoreData automatic model migration is great, but take care that it will work only with simple modifications...
Oh, just one another trick, add -com.apple.CoreData.SQLDebug 1 to your app launch arguments, and you will get all sql requests generated by CoreData... That might help you to understand the migration process. (and some other things...)
I have predefined tables in the database based on which I have to develop a web application.
Should I base my model classes on the structure of data in the tables.
But a problem is that the tables are very poorly defined and there is much redundant data in them (which I can not change!).
Eg. in 2 tables three columns are same.
Table: Student_details
Student_id , Name, AGe, Class ,School
Table :Student_address
Student_id,Name,Age, Street1,Street2,City
I think you should make your models in a way that would be best suited for how they will be used. Don't worry about how the data is stored or where it is stored... otherwise why go through the trouble of layering your code. Why not just do the direct DB query right in your view? So if you are going to create an abstraction of your data... "model" ... make one that is designed around how it will be used... not how it will be or is persisted.
This seems like a risky project - presumably, there's another application somewhere which populates these tables. As the data model is not very sound from a relational point of view, I'm guessing there's a bunch of business/data logic glued into that app - for instance, putting the student age into the StudentAddress table.
I'd support jsobo in recommending you build your business logic independently of the underlying persistance mechanism, and that you try to keep your models as domain focused as possible, without too much emphasis on how the database happens to be structured.
You should, however, plan on spending a certain amount of time translating your domain models into their respective data representations and dealing with whatever quirks the data model imposes. I'd strongly recommend containing all this stuff in a separate translation layer - don't litter it throughout the rest of the application.
I've been using Core Data for about a week now, and really loving it, but one minor issue is that setting default values requires going through and setting up a temp interface to load the data, which I then do away with once I have the data seeded. Is there any way to edit values in a table, like how you can use phpMyAdmin to manipulate values in a MySQL database? Alternately, is there a way to write a function to import seed values from something like a Numbers spreadsheet if it doesn't detect the storedata XML file?
For your first question, you could edit the file directly but it's highly recommended you don't. How to edit it depends entirely on the store type you selected.
Regarding importing or setting up pre-generated data, of course: you can write code to manually insert entity instances into your Managed Object Context. There's a dedicated section on this very topic in the documentation. Further, if you have a lot of data to import, there's even a section on how to do this efficiently.
Is there any way to edit values in a
table, like how you can use phpMyAdmin
to manipulate values in a MySQL
database?
Xcode has a means of creating a quick and dirty interface for a data model. You just drag the data model file into a window in interface builder and it autogenerates an interface for you. This lets you view the data without having to have your entire app up and running.