[TYPO3-dev] Raising Mysql requirements to 4.1?

[Steffen Kamper]

"Martin Kutschker" <Martin.Kutschker at n0spam-blackbox.net> schrieb im 
Newsbeitrag news:mailman.1.1191228477.1220.typo3-dev at lists.netfielders.de...
> Steffen Kamper schrieb:
>> "Martin Kutschker" <Martin.Kutschker at n0spam-blackbox.net> schrieb im 
>> Newsbeitrag 
>> news:mailman.1.1191226542.27232.typo3-dev at lists.netfielders.de...
>>> Hi!
>>>
>>> Now that TYPO3 4.2 will require PHP 5.1 it's time to think also about 
>>> Mysql requirements. Maybe TYPO3 will run on 3.23, but it's not 
>>> recommended, so I guess the true requirement is probably Mysql 4.0. But 
>>> only 4.1 offers true UTF-8 support and it would be nice if TYP3 could 
>>> start to rely on that fact. I think we could also require 5.0, but what 
>>> does theis mean to currrent installations? What is shipped with current 
>>> distros?
>>>
>>> Masi
>>
>> good idea - with php5 there is also mysql >=5 (geentoo, suse)
>> so good idea.
>> But what is main point with version 5? the most important step was 4.1 
>> which brought the collations.
>
> That's my reason for a minimum of 4.1
>
+1

>> Subqueries/stored procedures are also important extensions, but atm there 
>> is no use of it.
>
> You mean "no use in TYPO3 context" or generally? I don't think that TYPO3 
> should rely on stored procedures as there is no standard for them. But 
> aren't subqueries available in 4.1? It'd be nice to make use of them.

subqueries are implemented with 4.1 :-)
If there is a wrapper for that it can be used in extensions, later in core 
too.

>
>> Maybe with making the "native support" as discussed in PG thread there 
>> could be done some additional functions supporting
>> fulltext
>
> I have done research on that topic and can say now that it may be possible 
> to be a wrapper/API for that but syntax, configuration and features of 
> full text indices vary wildly.
>
>> replace
>
> AFAIK there is no standard for that and only Mysql supports it.

i only speak about the native mysql functions as we discussed in the PG 
thread from ries.

>
>> insert on duplicate key update etc.
>
> DB errors are seldom portable :-(

i thought about the double cache entry problem - could be solved in mysql 
using that syntax (see in BT), other db's may have simular function for 
that.

>
> Masi

vg  Steffen