[ECODP-dev] Migration 1.7 1.8

Mon Jun 17 09:05:08 UTC 2013

Hi Dimitrios,

Oh, no this doesn't sound ideal to me. I'm not sure why you need to install
a 1.8 database initially?

The old 1.7 database should be in place, then you install the package and
then finally upgrade it to 1.8. This is a similar process to previous
releases.

Regards,
John

On 17 June 2013 11:02, Dimitrios Mexis <dimitrios.mexis at tenforce.com> wrote:

> @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/644af1fe/attachment.html>