Long database names in apps break the update

[juliushaertl]

Apps that have a to long identifier name break the update.

So far I found:

• gpxmotion
• groupfolders
• mail "mail_collected_addr_userid_index" is too long. mail#1002
• notes
• music

Ref #10221

Is there anything we could do about that to avoid having the update stopped with those long names? Like can we just enforce the check on oracle and maybe only log a warning on other database types where this is not an issue?

Disabling the app also doesn't work, since the check is executed anyway.

cc @nickvergessen

[nickvergessen]

Like can we just enforce the check on oracle and maybe only log a warning on other database types where this is not an issue?

The thing is that would just obsolete the check all together, because no one of us ever installs oracle or checks the logs.

But yeah I will look into how we can improve the situation, so apps can have a compatibility upgrade going forward.

But also Note, if you make a new migration to fix your database layout, oracle still can't install, because the old table names you are using would need to install because migrations are applied incremental, not all combined into one batch.

[newsyrom]

i am having the same problem with ownbackup also.

[nickvergessen]

Had a couple of thoughts. But they all failed. The problem is we currently analyse all tables/columns/indexes/... everytime and not just the new ones. Otherwise we could have checked if the app supports oracle or not and only check it in case it does.

So my suggestion would be to only check the length in debug for 14 (or we simply disable the check in stable14 once its branched off) while we try to find a more clever solution for 15, which:

• respects apps which are not supporting oracle
• has a way for apps to migrate from a "broken" layout to a new one without big changes

Opinions @rullzer @ChristophWurst

[nickvergessen]

For a temporary solution you can delete

server/lib/private/DB/MigrationService.php

Line 460 in ef5074a

$this->ensureOracleIdentifierLengthLimit($targetSchema, strlen($this->connection->getPrefix()));

[icewind1991]

A big problem with this is that it doesn't limit the checks to apps that are currently enabled, meaning that you can't disable the problematic app and continue the upgrade.

[icewind1991]

Given how it checks against the entire database for each migration and not just the changed tables, I'm not even sure if you can solve this in the app if a core migration is triggered first.

[nickvergessen]

Work around for beta3: #10553

[icewind1991]

#10554 changes it to only check tables that are touched by a migration

[rullzer]

Fixed for 14 with #10553
Lets fix properly for 15 with #10555

[ghost]

Getting this error message

[rullzer]

@andyxh yes it is not released yet. Beta3 will be fixed. Which is scheduled for tomorrow.

[ghost]

Thank you! From: Roeland Jago Douma <notifications@github.com> Sent: Wednesday, August 8, 2018 1:49 PM To: nextcloud/server <server@noreply.github.com> Cc: andyxh <xhelia@outlook.com>; Mention <mention@noreply.github.com> Subject: Re: [nextcloud/server] Long database names in apps break the update (#10518) @andyxh<https://github.com/andyxh> yes it is not released yet. Beta3 will be fixed. Which is scheduled for tomorrow. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#10518 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AXb4Q3faBpVvZ4yrDm6VYz7rsLdubLLpks5uOzKegaJpZM4VtiGP>.

[shiftgeist]

It's been a while

The code appeared again in https://github.com/nextcloud/server/blob/master/lib/private/DB/MigrationService.php#L461

Installation goes brrrr

[nickvergessen]

Remove Oracle from support database list to get rid of it.

[code1x1]

@nickvergessen
Where do I have to remove Oracle from support database list?

[nickvergessen]

https://docs.nextcloud.com/server/latest/developer_manual/app_development/info.html

Check your info.xml file and add the database dependencies