[kronolith] No Data after Migration

[Michael J Rubinsky]

Simon Brereton <simon.brereton at dada.net> wrote:

>> -----Original Message-----
>> From: Michael J Rubinsky [mailto:mrubinsk at horde.org]
>> Simon Brereton <simon.brereton at dada.net> wrote:
>> 
>> >> -----Original Message-----
>> >> From: kronolith-bounces at lists.horde.org [mailto:kronolith-
>> >> bounces at lists.horde.org] On Behalf Of Simon Brereton
>> >> > -----Original Message-----
>> >> > From: Michael J Rubinsky [mailto:mrubinsk at horde.org] Simon
>> Brereton
>> >> > <simon.brereton at dada.net> wrote:
>> >> >
>> ><SNIP>
>> >> > >> >
>> >> > >> > Is that a hash of something so that I can just update that
>> >> > column?
>> >> > >>
>> >> > >> No, it's just a random hash, but such hashes were used in
>> >> > Kronolith 2
>> >> > >> too, for any calendars but your default calendar.
>> >> > >
>> >> > >Right - but right now, that hash is showing up as the default
>> >> > calendar.
>> >> > >
>> >> > >To bring back the calendar data I would have to add a new event
>> to
>> >> > each
>> >> > >calendar, and then replace the current calendar_id
>> >> (user at domain.com)
>> >> > >with the hash. (I've tested it and this works).  However, even
>> >> with
>> >> > my
>> >> > >limited user-base I'd rather not do that..  Especially if
>> everyone
>> >> > else
>> >> > >isn't having this issue.
>> >> >
>> >> > It sounds like either something went wrong for you during share
>> >> > migration, or maybe your not using the share backend that the
>> data
>> >> is
>> >> > stored in.
>> >>
>> >> Where would I debug that?  When I set up H4 I went with the
>> >> proposed/recommended option of SQl-NG.
>> >>
>> >> I did just discover (prior to your email) that this hash is also
>> in
>> >> kronolith_shareng as share_name and that changing share_name to
>> match
>> >> the share_owner/event_creator_id resolves this issue (although it
>> >> does mean when you first open the calendar you actually have to
>> tick
>> >> the calendar to display).  Ultimately when I do this migration in
>> >> production in two weeks time I can run the sql query update
>> >> kronolith_sharesng set share_name = share_owner after doing the
>> >> schema update without a problem, but it seems to a be sticking
>> >> plaster.
>> >>
>> >> I'm starting to wonder if during the upgrade I would have been
>> better
>> >> advised to run /usr/bin/horde-db-migrate and not use the update
>> >> schema's button in the config panel.  Another thread indicated
>> they
>> >> were essentially the same but Vilius and Andreas used that and
>> don't
>> >> seem to be having the issues I'm having.
>> >
>> >If it matters, my H3 share driver was DataTree.  But DataTree is
>> 
>> Sounds like you either didn't run the DT->sql share script or you ran
>> it after running the migrations.
>
>As per my original post, I let the Update All Schemas in the Config
>panel do all the heavy lifting.  Where is this script and at what point
>should I run it?  It sounds like I should do it after I point H4 at the
>H3 db and before I do Update All Schemas.  Yes?

As mentioned in UPGRADING each share app has this script, and it needs to be run before migrations if you are still using DT.  It's located in app/bin

--
Mike
Sent from mobile