6.0.0-alpha12
6/12/25

[#13331] Upgrade fails because script doesn't recognise name of shares tables
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

History
07/09/2014 11:43:49 PM software-horde (at) interfasys (dot) ch Comment #7 Reply to this comment

[Show Quoted Text - 10 lines]
I think I see what you mean. You want to keep the structure of as many 
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.
07/09/2014 11:29:31 PM Michael Rubinsky Comment #6 Reply to this comment
On the one hand, I understand your position. It's never been 
removed, so you keep the schema updated.
Yes, since some installations may have explicitly kept using the 
"legacy" share driver.
but if data is lost when switching between NG and non-NG (no data is 
migrated between tables),
If you run NG for some period of time and then switch back to non-NG, 
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.

07/09/2014 11:16:05 PM software-horde (at) interfasys (dot) ch Comment #5 Reply to this comment

[Show Quoted Text - 12 lines]
On the one hand, I understand your position. It's never been removed, 
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)
07/09/2014 11:00:02 PM Michael Rubinsky Comment #4 Reply to this comment
We've migrated properly in the past, but then switched to using 
sharesng and removed the old shares tables which only contained 
duplicated data.
You shouldn't perform operations like this outside of migrations.
Where are the old tables used? They were never kept in sync with the new ones
They are used if the installation is not using the "next generation" 
share driver. Both are still maintained.
07/09/2014 10:53:25 PM software-horde (at) interfasys (dot) ch Comment #3 Reply to this comment
If you don't have that table, you didn't migrate properly in the 
past. You must migrate from an up-to-date Horde 3 version, as 
clearly documented in the upgrade instructions.
We've migrated properly in the past, but then switched to using 
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


07/09/2014 09:17:07 AM Jan Schneider Comment #2
Priority ⇒ 1. Low
State ⇒ Not A Bug
Reply to this comment
If you don't have that table, you didn't migrate properly in the past. 
You must migrate from an up-to-date Horde 3 version, as clearly 
documented in the upgrade instructions.
07/08/2014 08:17:11 PM software-horde (at) interfasys (dot) ch Comment #1
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
Reply to this comment
Here is the message I get when trying to update the database schemas
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.

Saved Queries