|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0004078||mantisbt||feature||public||2004-07-13 01:06||2004-08-29 02:29|
|Target Version||Fixed in Version|
|Summary||0004078: Script to import the value of a custom field to a native field|
|Description||As we implement native field like fixed_in_version, it will needed to copy data in custom fields which users used to store this information into the newly created custom fields.|
In the example of fixed_in_version, the script should do the following:
- Take the custom field as an input from the user.
- Detect the projects that has this custom field linked.
- Iterate through all the issues in these projects and copy the value into the native field (if the value is valid, in this case valid means that it is one of the versions defined for the project).
- The output should be a page that logs the projects, and issues traversed, and should log the errors as well. This way. It would be nice if the issue numbers are hyperlinked to the issue view pages.
In my opinion, such scripts are like upgrade scripts and they should live somewhere under the admin/ folder.
|Tags||No tags attached.|
shouldn't this be a command line type script i.e. what happens if someone has say 20,000 bugs in their system, and php/web browser/proxy etc all have a 60 second 'timeout'? Same applies for moving database->disk.
I'd also be inclined to keep little 'helper scripts' seperate to the /admin area.
If you have php >4.3, there is a command line php that might be used. Otherwise, there could be a lot to re-implement in perl or another language.
In my testing, I transferred about 200 attachments in about 8 sec for 16M total. This was on a slow server (1GHz Powerbook).
|Building on the changes I made in 3714, here is an additional module to move a custom field to the fixed_in_version field. It should be fairly extensible to other fields.|
I was assuming command line php, rather then any other language. I'm assuming that most people would only move from mysql->file if they hit an issue e.g. they had 200,000 attachments and it was slowing the db down - and this is when i was thinking you might start hitting issues with a webbased script (or not?)...
Re, your patch, I don't seem to have move_db2disk.php here.
(Also, didn't we decide a few months back to use echo instead of print)
|move_db2disk.php is now in the files listed under 0003714. There is a second patch (file_down.diff) there to allow you to switch from database to disk without a move (e.g., new attachments are stored on disk, old ones in schema).|
|patch committed in CVS|
|2004-07-13 01:06||vboctor||New Issue|
|2004-07-14 21:59||vboctor||Priority||normal => high|
|2004-07-21 12:48||thraxisp||Relationship added||has duplicate 0003905|
|2004-07-22 12:19||thraxisp||Relationship added||related to 0003714|
|2004-07-22 12:23||thraxisp||Assigned To||=> thraxisp|
|2004-07-22 12:26||grangeway||Note Added: 0006239|
|2004-07-22 13:19||thraxisp||Note Added: 0006242|
|2004-07-23 14:20||thraxisp||File Added: mv_field.tar.gz|
|2004-07-23 14:22||thraxisp||Note Added: 0006258|
|2004-07-23 15:03||grangeway||Note Added: 0006259|
|2004-07-23 15:46||thraxisp||Note Added: 0006262|
|2004-07-23 16:11||grangeway||Relationship added||child of 0003987|
|2004-07-23 21:08||thraxisp||Status||new => assigned|
|2004-07-24 19:11||thraxisp||Status||assigned => resolved|
|2004-07-24 19:11||thraxisp||Resolution||open => fixed|
|2004-07-24 19:11||thraxisp||Note Added: 0006342|
|2004-08-29 02:29||vboctor||Status||resolved => closed|