I am using moodle 3.2 version. I did some changes in moodle database tables.For example i have added Schoolyear column in mdl_course table for my requirement purpose.When moodle migrate to next version the changes will affect or not?.
It is generally a bad idea to mess around with core Moodle database tables. It can cause problems during upgrades (and will not be included in backups, unless you change the core code as well), so it is usually better to store extra data in new tables.
That being said, there are occasions where it is really not practical to do anything else, and, usually, it does not cause too actual problems. The harder part is the merging of the core code changes that work with the changed database tables.
Related
We are using code first migrations to keep our database and model in sync. At the moment we have the version number as name for the migration which clearly doesn't work out.
The problem is that multiple migrations with the same name where created by different developers independent of each other for their local database. This led to some weird behavior as the IMigrationMetadata.Id was different because of the time stamp but the classes are partial with the same name.
What is the way to go to call these migrations? The examples are always ridiculously oversimplified: e.g. adding a property Readers result in migration AddReaders.
Or should the migrations be broken down to these little changes? Instead of having accumulate all the changes into one big migration. What if there are dependencies?
Yes, I think the best way is to break down changes to small units, with descriptive names. As with git, where you should commit often, with migrations you should migrate often. Not necessarily property by property, but containing a logical unit of work.
Like if you need to add two tables for some feature, add those two tables in one migration. Avoid making big migrations where your work for days changing models before creating a migration. Time is essential with avoiding conflicts.
If there are dependencies, one migration should contain related changes, so if another developer applies the migration, the application still works.
When a developer makes a migration, it should be immediately committed and synced (shared with other devs, in case you are not using git).
When you work with small units of change, merging and resolving conflicts becomes much easier.
I have been struggling with the same problem and trying out different solutions. What we have come up with so far is to have all the developers exclude the migrations from the check in process and then have one designated developer do the "release migration" that includes the changes from all the others working on the project.
I'm working on a major update of an iOS application. Let's say that we have two branches, develop contains what's currently on the App Store and feature/new_version the one with the major update.
feature/new_version has a lot of model changes, so there's a new model version there that adds/removes entities, properties, etc. On the other hand, we had a couple of minor improvements and bugfixes in develop, that caused the creation of new model versions as well (these were updates submitted to the App Store too).
Now I'm stuck with two branches with very different data models. The question is: If I add the "missing" properties to the feature/new_version model, will core data be intelligent enough to do an automatic lightweight migration when I submit the major update to the App Store? Or should I download the data model used in develop and create a new model version in feature/new_version based on that one and re-add / remove all the changes since I first created the branch?
Whether automatic lightweight migration works depends on the nature of the changes from the old model to the new one. In your case, the differences between the currently released version to the one in your new_version branch.
If the changes are just adding new attributes, no problem, this is the scenario that automatic lightweight migration was designed for. If they're more complex, you're more likely to need some alternate migration scheme. You didn't detail the changes, but since you said that the new version "adds/removes entities" automatic migration doesn't sound very likely. Adding in the "missing" properties won't help if there are structural changes to the model. Core Data doesn't mind simple migrations but won't infer a refactoring of the model structure.
How you create the merged model doesn't really matter as long as it contains everything you need. If adding the new properties is all it takes, there's no reason to start over. What matters is that the resulting model is correct, not the steps you took to get it there.
The easiest way to tell whether automatic lightweight migration will work is often to just try it on a debug build and see what happens. Install the currently released version on a device, create some data, and then use Xcode to install the new version. Make sure that NSMigratePersistentStoresAutomaticallyOption and NSInferMappingModelAutomaticallyOption are both YES when adding the persistent store. If it works, great. If not, Core Data provides alternatives for when the model needs more than trivial changes.
This is a question for those of you developing on a team of devs where all of you have separate databases. You're versioning your database using source control and other tools which will automatically bring dev databases up to date to the latest version of the database (schema, data, SP's, functions, etc.).
OK Great! But wait! What if you are developing on version 4.0 of your software, but now you need to switch branches to the 3.2 branch to fix a bug? The schema could be (almost assuredly is) very different by now...
I suppose if you went through the extra effort to write rollback scripts along with your change scripts, this could work. But that seems like a lot of work - is it really worth it?
Much easier would be to create a new 3.2-branch database and work with that while working on the 3.2-branch code. It doesn't seem reasonable to me to require that each developer has exactly one database to work with.
I'm going on a limb and assume that you are versioning the database as a binary? If all your database assets were in the form of constructive code (eg SQL scripts and/or text data dumps), the solution would be simple, as suggested by Mark: store these assets as part of the development branch. To work on version 3.2, switch the branch, re-run the create scripts and presto, 3.2 database. Merging would be just as easy as with regular code (or just as painful, depending on your version control system of choice).
Here are some suggestions to work in this mode:
If creating the database instances from text is too slow, make a cache on a shared disk volume, keyed by the contents of all the schema / data files (or the MD5 sum thereof).
Write a pre-commit hook to ensure that the schema and data dumps in the developer's instance are the same as the ones under version control. This prevents people from making changes to their dev database with an interactive tool, and then forgetting to commit them.
You mention change scripts; treat them as a liability. While they may be required by your deployment scenario (eg for customers who want to upgrade in-place), they duplicate information from the version history of the database, and per Murphy's law duplication means desynchronization sooner or later. Try to auto-generate the change scripts from the versioned database assets using "diff"; or if this cannot be achieved, dedicate some serious unit tests to database upgrades.
Still beavering away, slowly sorting out how things work. Today I've been looking at persistent stores and managed objects. I think I understand the basics of it all, but I've noticed something odd. When I save my managed object context and open up the resulting sqlite file in an editor, there are three tables there I don't expect. They're named after objects that I was originally using as managed objects, but later altered so that they weren't any more. I have no idea why they've been retained, since I've completely changed my file saving structure since then. No data gets put into these tables, but they keep cropping up. Is there any way I can remove them, or are they being added for some purpose I'm unaware of?
-Ash
Right, I have finally worked out where the extra tables were coming from, but it's a little bit weird.
Basically, I had tested a previous version of the application on OS3.2 to ensure backward compatibility. I later changed the format of the database, but by then I had moved to testing on OS4 exclusively. Somehow, the program was checking the SQLite files in both the 4.0 and the 3.2 directories and combining them into one big table. The extra tables were also responsible for causing errors when I tried to upload a desktop version of the database to my device, because the device's own version of the tables had a slightly different format thanks to the unwanted tables not being on there.
So the moral of this story folks is, always delete your program files from the simulator when you want to test for problems on a different OS.
-Ash
I am curious if there are any solutions out there, preferably free, that can have a central database to publish data to in a versioned manner.
For example,
Client 1 decides to edit a persons profile so it gets a local copy on its machine to make changes to. When they are happy with there edit they publish the results to the central database. Just like how you would do a submit in perforce.
Client 2 tries to edit the same local copy but when they go to submit they have to resolve conflicts.
The central database must store compressed differences between versions of the data.
At any point someone can look at all versions of the data submitted.
Check out OffScale DataGrove.
This product tracks changes to the entire DB - schema and data. You can tag versions in any point in time, and return to older states of the DB with a simple command. It also allows you to create virtual, separate, copies of the same database so each team member can have his own separate DB. All the virtual copies are tracked into the same repository so it's super-easy to revert your DB to someone else's version (you simply check-out their version, just like you do with your source control). This means all your DBs can always be synchronized.
Disclaimer - I work at OffScale :-)
"Version control of databases" is a bit ambiguous for a title, because you are actually asking for a VCS using a database as repository "data store".
Subversion has such a model (either Berkeley DB or filesystem-based).
It also has a Copy-Modify-Merge model which is similar to the kind of locking mechanism you are describing.
(source: red-bean.com)
(source: red-bean.com)
The sql tools from redgate sort of offer some of this functionality, but not implemented in a way you describe. For example, sql data compare can compare the differences between data in 2 databases, and sql source control can be used as well.
However, getting a copy of the database on a local machine, making changes and resubmitting would be more of a manual process.
What database server are you using? If you are using MySQL and PHP, Doctrine has 'Versionable' behavior which can be applied to a model.
The documentation on this behavior is here:
http://www.doctrine-project.org/projects/orm/1.2/docs/manual/behaviors/en#core-behaviors:versionable
This is exactly what my product (yes I'm biased :)) DBmaestro Teamwork does.
It enforces and keep track on the changes of structure and content
It prevents two parallel changes on an object structure or content by two (as long they work on the same object - meaning, same database, same schema, ...)
It uses a baseline aware analysis which understand the nature of the change and knows if the change should be promoted or should be ignored (as it was made from another environment) or if there is a conflict
And much more…
I would encourage you to read a comprehensive, unbiased review on Database Enforced Management Solution by veteran Database expert Ben Taylor which he posted on LinkedIn https://www.linkedin.com/pulse/article/20140907002729-287832-solve-database-change-mangement-with-dbmaestro