Summary | Upgrade fails because script doesn't recognise name of shares tables |
Queue | Horde Groupware Webmail Edition |
Queue Version | 5.2.0 |
Type | Bug |
State | Not A Bug |
Priority | 1. Low |
Owners | |
Requester | software-horde (at) interfasys (dot) ch |
Created | 07/08/2014 (3992 days ago) |
Due | |
Updated | 07/09/2014 (3991 days ago) |
Assigned | |
Resolved | 07/09/2014 (3991 days ago) |
Github Issue Link | |
Github Pull Request | |
Milestone | |
Patch | No |
backends as possible updated, to make it easy to switch from one to
another.
From my point of view, any structure check/migration could be
performed when the driver is changed or the data migrated via the
scripts you provide, but in this case, since the tables are so
similar, I can understand how it's easier to maintain that way,
instead of modifying the configuration scripts.
removed, so you keep the schema updated.
"legacy" share driver.
migrated between tables),
yes, then any new shares or perms that were changed since the switch
to NG would be lost. The idea of having both drivers isn't to allow
admins to switch back and forth at will, but rather to give a choice
in drivers. Originally, IIRC, some fringe cases were showing better
performance with the original driver (though this has probably changed
since then), so we continued to provide, and maintain both drivers.
This is no different than supporting different database backends, or
address book backends, or authentication backends etc... Just because
we provide different drivers to switch between doesn't mean that data
should be somehow automagically preserved when switching.
That being said, we DO offer a script that can convert between non-ng
and ng shares at will. We just don't offer the backwards conversion at
will since the idea is to move everyone towards the new driver anyway.
so you keep the schema updated, but if data is lost when switching
between NG and non-NG (no data is migrated between tables), then maybe
it would be best to update the schemas of what the installation is
using and to use scripts to migrate from one backend to another?
(I haven't checked if data is copied over when switching backend)
sharesng and removed the old shares tables which only contained
duplicated data.
share driver. Both are still maintained.
past. You must migrate from an up-to-date Horde 3 version, as
clearly documented in the upgrade instructions.
sharesng and removed the old shares tables which only contained
duplicated data.
Where are the old tables used? They were never kept in sync with the new ones
Priority ⇒ 1. Low
State ⇒ Not A Bug
You must migrate from an up-to-date Horde 3 version, as clearly
documented in the upgrade instructions.
Priority ⇒ 3. High
Type ⇒ Bug
Summary ⇒ Upgrade fails because script doesn't recognise name of shares tables
Queue ⇒ Horde Groupware Webmail Edition
Milestone ⇒
Patch ⇒ No
State ⇒ Unconfirmed
SQLSTATE[42S02]: Base table or view not found: 1146 Table
'webmail.turba_shares' doesn't exist
In our database, all the "shares" tables are named sharesng. It
probably happened when converting the backend from datatree to SQL.