Project

General

Profile

Actions

Bug #14513

closed

general problems with fulltext keys in tables (extension manager failures)

Added by old_jmziem almost 20 years ago. Updated over 18 years ago.

Status:
Closed
Priority:
Should have
Category:
-
Target version:
-
Start date:
2005-01-27
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
PHP Version:
Tags:
Complexity:
Is Regression:
Sprint Focus:

Description

if you use dbal(or even the old t3 system) the mapping of keys generate within
typo3\em\index.php funtion checkDBupdates()
>linked within install>getDatabaseExtra(...)
is simply wrong. the sql wrapper classes (class.db*, class.sql_*) only knows primary keys, [unique] keys and nothing else.

so if you add a fulltext key within your table, this extension manager ALWAYS want's to update the table, and it produces ALWAYS a table error - of course.

create an extension, and add within the ext_tables.sql within the table a fulltext index over a text field. this ALWAYS reproduced that error.

the problem itself came (i think) from field $diff:
em->index.php line 3576 (function checkDBupdates) where the getDatabaseExtra() stores the fulltext key as "unknown" and so as "FIELD" instead of key mark.
so the diff always failed.

i didn't understand the confusing system within the sql wrapper which tests and extracts all keys... so i couldn't fix it alone.
(issue imported from #M718)

Actions #1

Updated by old_jmziem almost 20 years ago

another note:
could someone change the regex while identifying keys and fields from one space to multiple spaces?
i mean, if you write your sql from the scratch there is no need for that, but we and i assume many other use dbdesign software which produces sometimes more spaces between keynames and tags etc.

it's so just an replacement of that preg_match etc.

Actions #2

Updated by Karsten Dambekalns almost 19 years ago

The DBAL classes/methods only support a subset of SQL. Furthermore to make the DBAL work cross-database, it must not use vendor specific SQL constructs.

Now: only [UNIQUE] INDEX is supported.

A FULLTEXT index is MySQL-only, this is why it isn't supported - and it will stay that way, just like the BITMAP index available on Oracle. If you have an extension that needs a fulltext index on MySQL you will have to create it manually or programmatically in that extension and document that. Sorry.

Actions #3

Updated by Karsten Dambekalns almost 19 years ago

If someone comes up with convincing reasons to include fulltext index support, I might change my opinion...

Actions #4

Updated by Karsten Dambekalns over 18 years ago

No really convincing arguments (none, to be exact) so far...

Actions

Also available in: Atom PDF