[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: 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.
<SNIP>
> >> >> 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

Michael

I've reread UPGRADING - but there is only one in the /imp and /horde directories - not one in /kronolith..

In the /horde one - I see this statement:

For shares,
you will need to upgrade each application individually. Applications that use
shares have entries in ``docs/UPGRADING`` and upgrade scripts
``app-convert-datatree-shares-to-sql`` for creating the SQL share tables and
migrating data.

On my H3 DB should I run the following in the following order

/usr/bin/horde-convert-datatree-groups-to-sql
/usr/bin/horde-convert-datatree-perms-to-sql
/usr/bin/horde-move-history-out-of-datatree
/usr/bin/ingo-convert-datatree-shares-to-sql
/usr/bin/kronolith-convert-datatree-shares-to-sql
/usr/bin/mnemo-convert-datatree-shares-to-sql
/usr/bin/nag-convert-datatree-shares-to-sql
/usr/bin/turba-convert-datatree-shares-to-sql
And then
/usr/bin/horde-db-migrate  (or just do the update DB Schema from the Config panel)

At which point should I run:
/usr/bin/horde-migrate-user-categories

Thanks.

Simon