Project

General

Profile

Feature #7595

Remove Upgrade from 1.6.x version and from 1.8.x

Added by Julio Montoya over 4 years ago. Updated over 4 years ago.

Status:
Feature implemented
Priority:
Normal
Assignee:
Category:
Installation / Migration
Target version:
Start date:
25/03/2015
Due date:
% Done:

50%

Estimated time:
Complexity:
Normal
SCRUM pts - complexity:
?

Description

We should drop the upgrade from 1.6.x and 1.8.x

If someone wants to migration to 1.10.x You should be at least in 1.9.x.

What do you think?

Associated revisions

Revision 2538b840 (diff)
Added by Julio Montoya over 4 years ago

Remove unused files see #7595

Revision 7a671cb4 (diff)
Added by Julio Montoya over 4 years ago

Add new migration structure see #7595

History

#1

Updated by Julio Montoya over 4 years ago

  • Subject changed from Remove Upgrade from 1.6.x version to Remove Upgrade from 1.6.x version and from 1.8.x
#2

Updated by Julio Montoya over 4 years ago

  • Description updated (diff)
#3

Updated by Yannick Warnier over 4 years ago

  • Status changed from New to Assigned
  • Assignee set to Julio Montoya
  • % Done changed from 0 to 10

In conclusion, we decided to go ahead and remove the possibility to upgrade directly from 1.6 and 1.8 to 1.10.
Users will have to first download a 1.9 version and upgrade to 1.9, then upgrade to 1.10.

This will allow us to definitively remove the backticks chars from our database queries, which will then enable better compatibility with other database management systems and engines.

This will also imply renaming at least the user, class and session tables to their plural version to avoid using reserved keywords from other database management systems. See http://www.petefreitag.com/tools/sql_reserved_words_checker/?word=sessions for compatibility stuff

#4

Updated by Yannick Warnier over 4 years ago

  • % Done changed from 10 to 30

Did you finish this one, Julio?
I see that you removed most upgrade files from main/install/ (where did they go??) and that you modified part of main/install/index.php, but I'm not sure you consider it finished...

#5

Updated by Julio Montoya over 4 years ago

  • Assignee changed from Julio Montoya to Yannick Warnier

Yannick Warnier wrote:

Did you finish this one, Julio?
I see that you removed most upgrade files from main/install/ (where did they go??) and that you modified part of main/install/index.php, but I'm not sure you consider it finished...

Old migrations files were deleted.

The upgrade from 1.9.x to 1.10.x is done using this file:

src/Chamilo/CoreBundle/Migrations/Schema/v1/Version110.php

The main/install/database.sql is not used anymore.
The installation process is done loading the Entities located here:

src/Chamilo/CoreBundle/Entity
src/Chamilo/CourseBundle/Entity
src/Chamilo/UserBundle/Entity

Change table:

- Update the entity + update the Version110.php migration file.

Create new table

- Create a new class inside one of those entities folders + create the table in Version110.php

#6

Updated by Yannick Warnier over 4 years ago

  • Assignee changed from Yannick Warnier to Julio Montoya

The current Version110.php is full of errors (mainly not closing the parenthesis correctly at the end of addSql() calls (phpstorms highlights them). I'll let you review that.

Could you be more specific about the install/upgrade process, and update chash about it?
As far as I can see, the "v1" folder would have to be extended with a "v2" on each database version change, right?

All things that are not either the Course table or the User table should be in the CoreBundle, right?

#7

Updated by Julio Montoya over 4 years ago

  • Assignee changed from Julio Montoya to Yannick Warnier

Yannick Warnier wrote:

The current Version110.php is full of errors (mainly not closing the parenthesis correctly at the end of addSql() calls (phpstorms highlights them). I'll let you review that.

I just fixed those.

Could you be more specific about the install/upgrade process, and update chash about it?

I didn't modified chash. Is a pending task.

As far as I can see, the "v1" folder would have to be extended with a "v2" on each database version change, right?

Yes. I just added a new file called Version111.php for the migration to 1.11 as an example.

All things that are not either the Course table or the User table should be in the CoreBundle, right?

Yes. Because in Chamilo 2, those bundles exist. The creation of new bundles is of course open to comments and suggestions.

#8

Updated by Yannick Warnier over 4 years ago

  • Assignee changed from Yannick Warnier to Julio Montoya
  • % Done changed from 30 to 50

Julio Montoya wrote:

Yannick Warnier wrote:

Could you be more specific about the install/upgrade process, and update chash about it?

I didn't modified chash. Is a pending task.

I'll let you do/follow that through the Github issues.

As far as I can see, the "v1" folder would have to be extended with a "v2" on each database version change, right?

Yes. I just added a new file called Version111.php for the migration to 1.11 as an example.

I meant for smaller versions, like for example 10.0.0.35 to 10.0.0.36 as we do now... How should we manage these progressive updates? All in the same file as we do now? In general, frameworks make each database changes count as a "migration" with a different number, so they know what they need to apply if things are updated through Git. Shouldn't we go in this direction and have migration versions that are independent of the Chamilo versions?

All things that are not either the Course table or the User table should be in the CoreBundle, right?

Yes. Because in Chamilo 2, those bundles exist. The creation of new bundles is of course open to comments and suggestions.

OK

#9

Updated by Julio Montoya over 4 years ago

  • Status changed from Assigned to Needs more info
  • Assignee changed from Julio Montoya to Yannick Warnier

Yannick Warnier wrote:

Julio Montoya wrote:

Yannick Warnier wrote:

Could you be more specific about the install/upgrade process, and update chash about it?

I didn't modified chash. Is a pending task.

I'll let you do/follow that through the Github issues.

As far as I can see, the "v1" folder would have to be extended with a "v2" on each database version change, right?

Yes. I just added a new file called Version111.php for the migration to 1.11 as an example.

I meant for smaller versions, like for example 10.0.0.35 to 10.0.0.36 as we do now... How should we manage these progressive updates? All in the same file as we do now? In general, frameworks make each database changes count as a "migration" with a different number, so they know what they need to apply if things are updated through Git. Shouldn't we go in this direction and have migration versions that are independent of the Chamilo versions?

I thought that for minor Chamilo versions we shouldn't make DB changes ..
Anyways, it's already the case. You can create many migration classes:

src/Chamilo/CoreBundle/Migrations/Schema/v1/Version110.php (1.10.0)
src/Chamilo/CoreBundle/Migrations/Schema/v1/Version1101.php (1.10.1)
src/Chamilo/CoreBundle/Migrations/Schema/v1/Version1102.php (1.10.2)
src/Chamilo/CoreBundle/Migrations/Schema/v1/Version111.php (1.11)

Or you can use the date or any string.

src/Chamilo/CoreBundle/Migrations/Schema/v1/Version20150316130422.php
src/Chamilo/CoreBundle/Migrations/Schema/v1/Version20150416130422.php
src/Chamilo/CoreBundle/Migrations/Schema/v1/Version20150516130422.php
src/Chamilo/CoreBundle/Migrations/Schema/v1/Version20150616130422.php

See: http://docs.doctrine-project.org/projects/doctrine-migrations/en/latest/reference/migration_classes.html

#10

Updated by Yannick Warnier over 4 years ago

It's not about database changes between minor versions, it's about the period of preparation for a major version (like now) and the fact that we need to frequently update the database.

Let's set the standard to: Version11020150422120000.php then, where we put the version first and then the date, yes?

I'm worried that with the first model you mentioned, we might get issues when moving from the following versions in order:
  • Version110.php
  • Version1101.php (1101>110, but also 1101>111)
  • Version111.php => will it detect that 1101 came before 111?
#11

Updated by Yannick Warnier over 4 years ago

  • Assignee changed from Yannick Warnier to Julio Montoya
#12

Updated by Julio Montoya over 4 years ago

  • Assignee changed from Julio Montoya to Yannick Warnier

Yannick Warnier wrote:

It's not about database changes between minor versions, it's about the period of preparation for a major version (like now) and the fact that we need to frequently update the database.

Let's set the standard to: Version11020150422120000.php then, where we put the version first and then the date, yes?

Is better then to do something like this:
Assuming that only database changes will apply in "1.10" and "1.11"

src/Chamilo/CoreBundle/Migrations/Schema/v1/110/Version20150422120000.php 1.10
src/Chamilo/CoreBundle/Migrations/Schema/v1/111/Version20160422120000.php 1.11
src/Chamilo/CoreBundle/Migrations/Schema/v2/200/Version20160422120000.php 2.0.0
src/Chamilo/CoreBundle/Migrations/Schema/v2/210/Version20160422120000.php 2.1.0
I'm worried that with the first model you mentioned, we might get issues when moving from the following versions in order:
  • Version110.php
  • Version1101.php (1101>110, but also 1101>111)
  • Version111.php => will it detect that 1101 came before 111?

According to the current policy we can't make DB changes in minor versions such as 1.10.1 so your scenario won't apply.

If you want to change that policy, then we use Version1100.php (1.10.0) and Version1110.php (1.11.0) (one more zero) so no problems here.

#13

Updated by Yannick Warnier over 4 years ago

  • Status changed from Needs more info to Assigned
  • Assignee changed from Yannick Warnier to Julio Montoya

I like
src/Chamilo/CoreBundle/Migrations/Schema/v1/110/Version20150422120000.php 1.10
src/Chamilo/CoreBundle/Migrations/Schema/v1/111/Version20160422120000.php 1.11
src/Chamilo/CoreBundle/Migrations/Schema/v2/200/Version20160422120000.php 2.0.0
src/Chamilo/CoreBundle/Migrations/Schema/v2/210/Version20160422120000.php 2.1.0

Let's go with that.
Can you reshape the current structure? As soon as you're done, I'll already make one small change to set Spanish as parent of Quechua and Spanish_latin, and then move most settings from configuration.php to settings_current.

#14

Updated by Julio Montoya over 4 years ago

Yannick Warnier wrote:

I like
src/Chamilo/CoreBundle/Migrations/Schema/v1/110/Version20150422120000.php 1.10
src/Chamilo/CoreBundle/Migrations/Schema/v1/111/Version20160422120000.php 1.11
src/Chamilo/CoreBundle/Migrations/Schema/v2/200/Version20160422120000.php 2.0.0
src/Chamilo/CoreBundle/Migrations/Schema/v2/210/Version20160422120000.php 2.1.0

Let's go with that.
Can you reshape the current structure? As soon as you're done, I'll already make one small change to set Spanish as parent of Quechua and Spanish_latin, and then move most settings from configuration.php to settings_current.

Great, I will do the changes.

#15

Updated by Julio Montoya over 4 years ago

  • Status changed from Assigned to Feature implemented

Also available in: Atom PDF