[ECODP-dev] Migration 1.7 1.8

Mon Jun 17 08:53:29 UTC 2013

Hello Dimitrios, Bert,

> Three problems though and I would like your comments:
>
> a) Git pull during the process.

I'm not sure what you are referring to here, can you elaborate? If you have
the latest versions of the code before you build your RPM then a further
Git pull should not be required.

> b) the Create table fails, so can it be replaced with a check whether
exists or not, and drop the tables before issuing the create
> command again ? Perhaps if they are empty as I looked them, it's safe.
What do you think ?

I'm not sure which create table command you are referring to here. In
general however this sounds very dangerous to me. If you are running
something to create tables that already exist this sounds like an error and
should fail. We don't want to lose data here by dropping tables that should
not need to be recreated in the first place.

Are you running through the commands starting with a clean CKAN 1.7
database? If not, I would expect some of the commands to fail.

> c) As an example of a wierd case: The directory to the resource is:
>
/applications/ecodp/users/ecodp/ckan/var/file-storage/pairtree_root/de/fa/ul/t/obj/2013Mar24232453
> but the url is like:
> data/storage/f/2013Mar24232453/demonstrator.rdf
>
> Even if I configure apache to fetch the file-storage as storage, the rest
of the path is not equal. Is that ok?

> in addition to this in the rdf you generate you put
> "open-data/data/storage/f/2012-12-19T104622/accreditedPersons.xsd"^^<
http://www.w3.org/2001/XMLSchema#anyURI>

I will have a look at these two issues, it is possible that there is a bug
or misconfiguration in the storage system as it has not been used in the
project to date.

Regards,
John

On 14 June 2013 08:59, Bert Van Nuffelen <bert.van.nuffelen at tenforce.com>wrote:

> Hi,
>
> in addition to this in the rdf you generate you put
> "open-data/data/storage/f/2012-12-19T104622/accreditedPersons.xsd"^^<
> http://www.w3.org/2001/XMLSchema#anyURI>
>
> which should be a proper URL. Also I see the addition prefix open-data
> which has been removed sinces 00.07.50.
>
> kind regards,
>
> Bert
>
> 2013/6/14 Dimitrios Mexis <dimitrios.mexis at tenforce.com>:
> > It seems the datasets are migrated after all.
> > 5805.
> >
> > Three problems though and I would like your comments:
> >
> > a) Git pull during the process.
> >
> > b) the Create table fails, so can it be replaced with a check whether
> exists
> > or not, and drop the tables before issuing the create command again ?
> > Perhaps if they are empty as I looked them, it's safe. What do you think
> ?
> >
> >
> > c) As an example of a wierd case: The directory to the resource is:
> >
> /applications/ecodp/users/ecodp/ckan/var/file-storage/pairtree_root/de/fa/ul/t/obj/2013Mar24232453
> > but the url is like:
> > data/storage/f/2013Mar24232453/demonstrator.rdf
> >
> > Even if I configure apache to fetch the file-storage as storage, the
> rest of
> > the path is not equal. Is that ok ?
> >
> >
> > Regards
> > Dimitrios
>
>
>
> --
> Bert Van Nuffelen
>
> Semantic Technologies Software Architect at TenForce
> www.tenforce.be
>
> Bert.Van.Nuffelen at tenforce.com
> Office: +32 (0)16 31 48 60
> Mobile:+32 479 06 24 26
> skype: bert.van.nuffelen
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.okfn.org/mailman/private/ecodp-dev/attachments/20130617/11086015/attachment.html>