Bug #1148
closedDEF_timestamp is NULL
0%
Description
I just noticed that all of our processing (ap*) databases that were created after upgrading to 2.0 several months ago have NULL as the default for all the "DEF_timestamp" columns. Is this a problem with our installation of mysql/leginon/appion, or a bug in appion?
All the processing databases that were created before the upgrade still have the correct DEF_timestamp settings & values.
New processing databases look like this:
@-----------------------------------------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |-----------------------------------------------+------+-----+---------+----------------+
| DEF_id | int(20) | NO | PRI | NULL | auto_increment |
| DEF_timestamp | timestamp | YES | MUL | NULL | |
@
But they should look like this, right?
@-----------------------------------------------+------+-----+-------------------+----------------+
| Field | Type | Null | Key | Default | Extra |-----------------------------------------------+------+-----+-------------------+----------------+
| DEF_id | int(20) | NO | PRI | NULL | auto_increment |
| DEF_timestamp | timestamp | NO | MUL | CURRENT_TIMESTAMP | |
@
Updated by Amber Herold almost 14 years ago
- Status changed from New to Duplicate
- Affected Version changed from Appion/Leginon 2.1.0 to Appion/Leginon 2.0.0
Updated by Eric Hou almost 14 years ago
I guess it might be easier if Gabe and others can upgrade to 2.1
There are lots of fixed after 2.0, and if we need to merge all of them to 2.0, it might takes lots of time.
Eric
Updated by Anchi Cheng almost 14 years ago
If this appears in ap* database, this is not resolved by the fix in #942 that only fixed newly created LaunchedApplicationData which Gabe didn't have to do. Update to 2.1 will not be the solution for future ap* to have this problem.
Gabe, Could you tell us what tables gave you this bad schema so that we can find the specific error easier? Upon creation of ap database, tables are created from loaded xml files both because some need rows entered, like apSymmetryData ( through myamiweb/project/defaultprocessingtables.xml), or because processing webpages want to query them even if nothing is run under the catagory, such as various 2D alignment method. to generate counts of total runs( through myamiweb/xml/appion_extra.xml). These xml files might not be quite right if you are having this problem.
Updated by Anchi Cheng almost 14 years ago
- Status changed from Duplicate to Assigned
- Assignee changed from Amber Herold to Gabriel Lander
Branch 2.0 does not have bug #942 because I discovered and fixed it before its final release in r14380. The bug appears in branch 2.1 because I forgot to merge that fix back to trunk at the time.
Updated by Amber Herold almost 14 years ago
Quite right. Sorry for confusion. I don't see the problem in our installation or the test installation.
Updated by Gabriel Lander almost 14 years ago
Ok these are the affected tables, all the rest look ok:
ApAppionJobData
ApInitialModelData
ApPathData
ApSymmetryData
ApTemplateImageData
Updated by Eric Hou almost 14 years ago
I just installed a new 2.1 in my test machine. All the timestamp are set to not null. So it might just effect to 2.0 installation.
To fix your time stamp problem here is the query you can use:
ALTER TABLE ApAppionJobData MODIFY `DEF_timestamp` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP;
Just change table name for different table.
Thanks.
Eric
Updated by Eric Hou almost 14 years ago
- Assignee changed from Gabriel Lander to Eric Hou
Just fixed the default ap database's tables time stamp problem.
This fixed need to merge to branch 2.0, 2.1
Thanks.
Eric
Updated by Eric Hou almost 14 years ago
- Status changed from Assigned to In Code Review
- Assignee changed from Eric Hou to Anchi Cheng
Updated by Eric Hou almost 14 years ago
Anchi!
After you merge the fixed to branch, can you assign this bug back to me, so I will write a update script.
Thanks.
Eric
Updated by Anchi Cheng almost 14 years ago
- Status changed from In Code Review to Assigned
- Assignee changed from Anchi Cheng to Amber Herold
r15293 reviewed and tested
merged to branch-2.0 as r15294; to branch-2.1 as r15295.
Amber, Please repackage releases for both branches and assign the bug back to Eric to write the patch for damaged database.
It appears that our own database default to not null when it is not assigned. Which is why we didn't see it earlier. Must be a database settings.
Updated by Amber Herold almost 14 years ago
- Assignee changed from Amber Herold to Eric Hou
Nice work on this guys.
I think Eric should write the script before I package it though, so that the script is in the package.
Eric, please assign back to me when You are done.
Updated by Amber Herold almost 14 years ago
- Target version set to Appion/Leginon 2.1.2
Updated by Eric Hou almost 14 years ago
- Status changed from Assigned to In Test
You can use the script I post before to fix this problem now. We already have a new patch to fix this problem but not ready for release yet. The update scripts will be release in 2.2 and also be ready to download in Trunk shortly.
Here is the script again:
ALTER TABLE ApAppionJobData MODIFY `DEF_timestamp` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP;
Thanks.
Eric
Updated by Anchi Cheng almost 14 years ago
To fix the damaged database, patches are made using what developed for feature #345 so if this is tested, those development are, too. Feature #345 is still not fully automated, only semi-automated.
Testing:
1. Use older svn checkout or releases of either 2.0 or 2,1 branch to create databases, including a processing database for a test project.
2. Update the svn checkout to head or package a new release after the fixes (r15303 for 2.0 and r15300 for 2.1).
3. Go to dbschema directory and run schema_update.py It will print out a list of command to paste into shell.
4. If an earlier command fail, the next would not execute. If you lost track of the list, just repeat 3. It will give you a updated list.
Updated by Eric Hou almost 14 years ago
- Assignee changed from Eric Hou to Amber Herold
Updated by Amber Herold almost 14 years ago
Found a few issues with this.
1. when run from the installation directory, it can't find the web directory to look up the current revision number
2. it can't use the leginon library to check the svn file for the revision because once the library is installed, the svn file is not available
Anchi is working on a solution.
Updated by Amber Herold almost 14 years ago
- Assignee changed from Amber Herold to Anchi Cheng
Updated by Anchi Cheng almost 14 years ago
- Assignee changed from Anchi Cheng to Amber Herold
r15324 uses dbschema path as the starting point to get svn info and xml path so that it will work with installation. r15325 is the same in branch 2.1; r15326 is the same in branch 2.0
This works because dbschema is not installed to python site-packages, It is important though that the installation instruction is such that people who download the release make copy of the myamiweb directory to webserver location, not move, or the script will still fail.
Testing:
1. Download or check out the desired myami in /tmp or local directory.
2. Install with python installer and COPY myamiweb to its webserver location
3, go to dbschema in the checkout or download myami directory
4. run dbschema_update.py
5. Follow the rest of testing as before.
Updated by Amber Herold almost 14 years ago
- Status changed from In Test to Closed
The DEF_timestamp is NULL problem is fixed. The update script tests out well.
Updated by Amber Herold over 12 years ago
- Target version changed from Appion/Leginon 2.1.2 to Appion/Leginon 2.0.5