[ECODP-dev] Migration 1.7 1.8

[Dimitrios Mexis]

@Bert/John
The process we agreed would be 1.8 installation [ db=1.8, frontend = 1.8 ]
and then pg_restore ( the old 1.7 ) over the 1.8 db.[db=1.8->1,7 frontend =
1.8]
Then the 1.7 that EVENTUALLY been restored, would be upgraded from the
interface of 1.8 [db=1.7->1.8 frontend=1.8 ]

I had to delete two tables and then I did the upgrade. which didn't result
to any obvious errors.

Assess on 192.168.33.87 frontend 192.168.33.78 <-db

regards
Dimitrios


On Mon, Jun 17, 2013 at 10:53 AM, John Glover <john.glover at okfn.org> wrote:

> 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/1f24635b/attachment.html>