[ckan-dev] migrate repository

[James Gardner]

Sounds good. In that case I'll make the changes to my branch then.

Cheers,

James


On Fri, 2011-02-11 at 13:29 +0000, David Raznick wrote:
> 
> 
> 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 list
>         > ckan-dev at lists.okfn.org
>         > http://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
>         
> 
> _______________________________________________
> ckan-dev mailing list
> ckan-dev at lists.okfn.org
> http://lists.okfn.org/mailman/listinfo/ckan-dev