[FLOW3-general] DateTime limited to Unix timestamp?

[Jigal van Hemert]

On 10-10-2010 20:04, Martin Kutschker wrote:
> Am 09.10.2010 15:16, schrieb Jigal van Hemert:
>> 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.

Maybe I have to explain to some that I meant this not as an opinion for 
support of raw queries, but as a warning that support of raw queries 
will have consequences for an entire product later on: as soon as there 
are a few major "extensions" available which use raw queries it is less 
likely that they will ever be removed and thus the product is kind of 
locked to a limited number of supported DBMSs.

> IMHO FLOW3 should allow raw SQL only for one reason: performance. At a certain point in the
> development/deployment you may find yourself in the need of streamlining the disc/DB access.

The most performance gain can be found in optimizing algorithms. The 
next step can be caching and after that you can look at small code 
optimizations in bottle necks. Proper database structures and "queries" 
(in the broadest sense of the word) are an essential part of a DB 
specific backend.

> An interesting question is if FLOW3 should provide a DBAL like API for that. If you really want to
> tune the system you probably want to get the most of the features of your RDBMS. So you don't want
> an extra layer between your SQL and the DB.

If you mean a DBAL like v.4 has, then please no. With all due respect to 
the creators and maintainers of this system extension, but the way it is 
built (a rewrite engine for queries) was necessary because the system 
allowed raw queries.

For an enterprise level system it's actually more important that it runs 
on a wide range of systems than that it has a bit extra performance. If 
a large company has all their systems running on DB system 'X' it's 
actually simpler and cheaper to add extra hardware for the new CMS than 
it is to use a different database system. In fact it's very likely that 
the company will put support for their DB system 'X' in the requirements 
when selecting a new CMS.

A layer to translate requests to DB specific queries doesn't need to 
cost a lot performance wise. An optimized DB specific backend can be a 
lot faster than badly written raw queries.

-- 
Kind regards / met vriendelijke groet,

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