[kronolith] No Data after Migration

[Simon Brereton]

> -----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?

Simon