[FLOW3-general] DateTime limited to Unix timestamp?

[Jigal van Hemert]

Hi,

On 8-10-2010 19:01, Michael Sauter wrote:
> Question: What good is the specific datatype if you have a string
> representation in the abstraction?

Performance (using as many DBMS specific features in the DB backend to 
optimize performance) and storage space mainly.

The interface with the data storage abstraction layer should use a 
general format while the database specific implementation can use the 
most optimal way to store and process the data.

> If on the other hand, you want to have an abstracted way of dealing with
> dates (this way really making use of a specific date/time datatype), you
> have to provide the abstraction for all backends, which IMHO will be
> really difficult to do.

If you use real abstraction with the benefit of being completely 
independent of the backend used for actual storage you need to build a 
query "language" of your own (the "language" can consist of a series of 
functions, or a more complex API, or a textual language, or some other 
format which fits the application). Depending on the features you want 
to include it can be more or less complex to do.

I really expect FLOW3 to have such an abstract implementation which is 
completely independent from the actual storage type.

>> If the support in Extbase for raw queries is just there for backwards
>> compatibility this would mean that porting extbase-based extensions to
>> FLOW3 packages will be a lot harder than advertised. If it is there
>> because FLOW3 supports it the use of storage mechanisms other than SQL
>> databases will remain a dream.
>
> Why? If you use raw queries, then well, you're stuck with SQL. Not that
> much of a problem because atm, there are only SQL backends, right? If
> there will be something else in the future and you want to use your
> extension with a different backend then you might have to adjust it.
> Where's the problem? Do you expect FLOW3/Extbase to rewrite your
> extension for you?

The situation with TYPO3 v.4 is that there is a DBAL system extension 
which is able to rewrite a lot of SQL queries for a number of DBMSs. The 
core the supported features of DBAL and it is thus possible to install 
v.4 directly on one of the supported DBMSs. Many extensions use various 
MySQL specific features and can not be used successfully on other DBMSs.

If FLOW3 will support raw queries there will be less need to make a 
feature rich API, because problems can easily be solved with raw queries.

TYPO3 is not only the core, but the entire system with 
extensions/packages. With v.4 some of the major extensions such as 
tt_news are not DBAL compatible. So it is impossible to move most TYPO3 
websites to a different DBMS without altering several extensions.
I don't think this situation should be repeated with FLOW3.

A more serious reason to not want raw queries is security. Even though 
the v.4 API has functions to quote and escape external data for use 
inside queries there are still regularly security bulletins about SQL 
injection problems in extensions.
An abstracted storage layer must take care of this.

Last of all, Michael Feher also introduced an important argument against 
using Unix timestamps; data which is persisted must be returned 
unmodified. With the difference in supported range between the DateTime 
object and a Unix timestamp this will never be the case with the current 
implementation.

The complete rebuild of TYPO3 with a new framework is *the* chance to 
improve the basis of a CMS and learn from the experience of v.4. I 
sincerely hope that the result will be a system which is in the first 
place a solid, secure framework and not a collection of "cool" and 
"state of the art" techniques. If I see raw queries and Unix timestamps 
I can't be too optimistic :-(

-- 
Kind regards / met vriendelijke groet,

Jigal van Hemert
skype:jigal.van.hemert
msn: jigal at xs4all.nl
http://twitter.com/jigalvh