I seem to be having issues due to this version change. My module original had the version as #1 and #2 but the module fails to update. When I read the documentation it still has the old versioning: http://lemonstandapp...tabase_tables/.
When I look in shop/updates it has 06815d8.sql file. Can we have some clear documentation on how the .sql or .php files should be named in response to this new version system #1.0.2?
Page 1 of 1
Confused
#2
Posted 15 December 2011 - 05:30 PM
HI!
The versioning notation described in the documentation still works. We have updated LS versioning to satisfy our internal development needs, and now we can use SQL update files which do not belong to any version. But you still can use the old scheme:
Here is the updated versioning approach, from our internal documentation, if you are interested:
New format of version.dat
1. The file can now contain references to update files (SQL or PHP). References can be defined in separate lines or in the version declaration (see item 2). Reference definitions should start with the at (@) symbol: @abc12de45. A value after the @ symbol used as the update file name. For example, for reference @abc12de45 LemonStand will look for files abc12de45.sql and abc12de45.php in the updates directory and execute them if they exist. Multiple references can be defined in a single line, separated with the pipe (|) symbol: @abc12de45|@abc12de46. (We have a special tool for generating update codes. We can share it in the future).
2. Each version line should start with the hash (#) symbol suffixed with the version number and optionally with a list of update references, separated with the pipe symbol. Spaces are not allowed in the version number, update references and between them. Version number should be defined as 3 numbers separated with the period (.) symbol. After the version number (and update references) goes the version description. Examples:
3. For backward compatibility we still support the old syntax with the build number and optionally without the version number, but the old format should not be used for new versions. The following version.dat format is still valid:
Example of version.dat file which includes all supported features:
How LemonStand applies database updates
When LemonStand finds an update reference in version.dat file it first checks whether this update has not been executed earlier. If the update has been executed, LemonStand skips it. It allows us to add database updates to version.dat file independently of version numbers during some feature development. Before the feature is published, the project manager merges update references under a single version number and publishes the update. After that the module developer can safely check out the updated module and this will not break the database because all updates mentioned in the version.dat have already been applied earlier.
The versioning notation described in the documentation still works. We have updated LS versioning to satisfy our internal development needs, and now we can use SQL update files which do not belong to any version. But you still can use the old scheme:
#1 Module initialization - there could be 1.sql file for this version #1|1.0.1 Module initialization - there could be 1.sql file for this version
Here is the updated versioning approach, from our internal documentation, if you are interested:
New format of version.dat
1. The file can now contain references to update files (SQL or PHP). References can be defined in separate lines or in the version declaration (see item 2). Reference definitions should start with the at (@) symbol: @abc12de45. A value after the @ symbol used as the update file name. For example, for reference @abc12de45 LemonStand will look for files abc12de45.sql and abc12de45.php in the updates directory and execute them if they exist. Multiple references can be defined in a single line, separated with the pipe (|) symbol: @abc12de45|@abc12de46. (We have a special tool for generating update codes. We can share it in the future).
2. Each version line should start with the hash (#) symbol suffixed with the version number and optionally with a list of update references, separated with the pipe symbol. Spaces are not allowed in the version number, update references and between them. Version number should be defined as 3 numbers separated with the period (.) symbol. After the version number (and update references) goes the version description. Examples:
#1.6.27 Version description #1.6.28|@abc12de45|@abc12de46 Version description
3. For backward compatibility we still support the old syntax with the build number and optionally without the version number, but the old format should not be used for new versions. The following version.dat format is still valid:
#12 Version description #627|1.6.27 Version description
Example of version.dat file which includes all supported features:
#1 Version description #2|1.0.2 Version description @abc12de45|@abc12de46 #1.0.3|@abc12de45|@abc12de46 Version description Second line
How LemonStand applies database updates
When LemonStand finds an update reference in version.dat file it first checks whether this update has not been executed earlier. If the update has been executed, LemonStand skips it. It allows us to add database updates to version.dat file independently of version numbers during some feature development. Before the feature is published, the project manager merges update references under a single version number and publishes the update. After that the module developer can safely check out the updated module and this will not break the database because all updates mentioned in the version.dat have already been applied earlier.
#3
Posted 12 January 2012 - 04:35 PM
I seem to be having issues with the database updates. I created a new line in version.dat with the following:
The contents of a83e012.sql are:
I uploaded these changes, logged out of the LS admin area, and logged back in. Then I looked in phpMyAdmin and smartvendorsync_increment was not updated.
Did I do something wrong? Is there a step missing?
I ended up making the change to the database manually, but I'd really like to understand how this works in the future so I can do this more easily.
Thanks!
[EDIT]
It's worth noting that the version number did bump as expected in the Modules & Updates page on my dashboard.
#1.0.1|@a83e012 Updated the increment table to accommodate more categories
The contents of a83e012.sql are:
ALTER TABLE `smartvendorsync_increment` MODIFY `categories` TEXT NOT NULL;
I uploaded these changes, logged out of the LS admin area, and logged back in. Then I looked in phpMyAdmin and smartvendorsync_increment was not updated.
Did I do something wrong? Is there a step missing?
I ended up making the change to the database manually, but I'd really like to understand how this works in the future so I can do this more easily.
Thanks!
[EDIT]
It's worth noting that the version number did bump as expected in the Modules & Updates page on my dashboard.
#4
Posted 15 January 2012 - 02:16 PM
Hi Jason,
Hm, everything looks correct. Can you create another test SQL update? You can add references to SQL files independently of versions:
Thank you
Hm, everything looks correct. Can you create another test SQL update? You can add references to SQL files independently of versions:
#1.0.1|@a83e012 Updated the increment table to accommodate more categories @a83e013
Thank you
Share this topic:
Page 1 of 1

Help













