[FLOW3-general] DateTime limited to Unix timestamp?

[Michael Sauter]

Hi,

On 09.10.10 14:16, Jigal van Hemert wrote:
> 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.

I don't get it ... first you're saying this, later on you go about 
allowing raw queries being a bad thing. From what you write, I get the 
impression that you're not really familiar with FLOW3 persistence, which 
is not a good basis for a discussion.

> 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 :-(

As already pointed out (also by Karsten himself), there certainly is a 
better solution to storing date/time. As I suggested earlier, I would 
use strings to solve the range problem (thus making sure that what you 
store is what you get back). Then you can improve on this and store it 
in a specific DATETIME field where possible, for performance reasons, 
you're right.

And concerning raw queries: I completly agree with Michael Feher that 
allowing raw queries is a good thing (actually, who can hinder someone 
using them anyway? At some point the framework has to make a raw query) 
but they should not be encouraged (which they are not in FLOW3). 
Whereever possible, use the abstraction provided (which is already 
there) so that it is easier to switch to another database which might 
feature a slightly different SQL "dialect" or has no SQL at all.

I really suggest you have a deeper look at the source code of FLOW3 and 
make your own judgments based on that and not what you hear whether it 
is solid or not. And if there are specific problems, point them out or 
fix them.

I think concerning the issue with date/time, I made a suggestion (and 
I'm open to use a DATETIME field for databases that feature this, 
although I don't know yet how much more work it would be) and I think we 
should wait for the core team to have their say on this when they find 
time.

~michael