[ckan-dev] migrate repository

[David Raznick]

On Fri, Feb 11, 2011 at 12:49 PM, James Gardner <james at 3aims.com> wrote:

>  Hi David,
>
> This is great work!
>
> The harvesting_job.errors field is not needed, don't know where it came
> from. Errors are now stored as part of the .report attribute in the "errors"
> key of a JSON dictionary. I'll remove it from the model in the current
> harvesting branch if you could fix the migration please? On the same table
> I'm going to add these two columns to harvesting_job, both default to NULL.
>

>     Column('started', DateTime),
>     Column('finished', DateTime),
>
> Whist you are tidying up the migrate scripts for harvesting_job could I
> please ask you to add those columns in the migrate script too and I'll add
> them in the model. Once you've committed I'll merge default back into the
> branch so that we should be correct moving forward.
>
> Sound good?
>

I think, in that case, we should just pretend that errors field never
existed.  i.e do not change any migrate scripts and just move it out of the
current model.

There is a chance that some live database will have it as a field already.
 This should not cause problems, it will basically be an unused field in the
database and as its nullable will not effect those databases.

I am happy to add a 'new' migrate script for this case outlined above. It
would be better added directly to your branch.



>
> I don't know about authorization_group_user.id I'm afraid.
>
> Cheers,
>
> James
>
>
>
>
>   * harvesting_job.errors
>  * authorization_group_user.id
>
>  Can anyone give me help to decide where in the migrate scripts these
> should be added?
>
>  If you add them too early then people upgrading after that point will
> still not have them.  Too late and people may already have them and the
> upgrade will crash.   I do not want to resort to having logic in the migrate
> scripts i.e if you already have the field don't bother, but this might have
> to happen.
>
>  On top of this there are
>
>   * 14 fields which are stated as not null in the model and nullable in
> the repository.
>  * 2 occasions where joint primary keys are being made in the  that are not
> in the current mode.
>
>  I am trying to sort this out by making a plugin that runs db clean, db
> update before each tests (ticket 965).  This is what flagged the issues.
>
>  It would be good if we could be in a state where we could run update db
> instead of create db when creating a new ckan instance.  Currently we are
> not.
>
>  David
>
>
>
>
> _______________________________________________
> ckan-dev mailing listckan-dev at lists.okfn.orghttp://lists.okfn.org/mailman/listinfo/ckan-dev
>
>
>
> _______________________________________________
> ckan-dev mailing list
> ckan-dev at lists.okfn.org
> http://lists.okfn.org/mailman/listinfo/ckan-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/ckan-dev/attachments/20110211/f39887e1/attachment-0001.html>