[FLOW3-general] DateTime limited to Unix timestamp?

[Jigal van Hemert]

Hi,

On 7-10-2010 22:27, Michael Sauter wrote:
> While I agree that it would be very useful to use some sort of
> DATE/DATETIME datatype, I don't think it is a good idea to rely on them.
> FLOW3 abstracts the complete storage away. Because of this, potentially
> any database could be used. For example, CouchDB [1] can "only" store
> String, Number, Boolean, Array and Object. Now I don't know if CouchDB
> would be a good fit for FLOW3, but I would consider it a "decent" DBMS.
> It's just not relational (and doesn't use SQL). And there are many more
> systems like CouchDB that do not support specific date/time datatypes.

If an abstraction layer is introduced in the system which completely 
hides the details of the storage mechanism (I use this term because it 
is now a black box instead of a known DBMS), then that abstraction layer 
is responsible for processing requests, converting data, etc. which goes 
into the storage mechanism and which comes out of the storage mechanism.

The problem I noticed in the beginning of this thread is that FLOW3 
currently converts the DateTime object (which has a decent range of 
values) to a Unix timestamp before storing (sorry, persisting) it in the 
storage mechanism.
This is a wrong approach IMO.
If the storage is completely abstract then the abstraction layer is 
responsible for converting the data to the appropriate type which is 
used for storing data.

It would be possible (and maybe logical) to have certain string format 
internally for dates/times, which can be converted to the appropriate 
value in the storage. If you use a RDBMS a date/datetime field could be 
used and for NoSQL databases a string field could be appropriate.
The abstraction layer is also responsible for using the right format to 
enable correct sorting, comparing, etc. and for building the appropriate 
requests (queries for RDBMS) for the used storage type.

> I also think that it would be great to have a non-relational database
> backend for FLOW3 at some point, because it could fit much better with
> DDD approach taken (also for scaling/performance reasons).

The system must have a completely abstracted layer to make this 
possible. Judging by the various methods in Extbase (there are still 
direct queries possible) and the way DateTime objects are currently 
persisted I am not so sure if this is really abstract.

> So, in order to be able to switch the underlying database without
> changing client code, FLOW3 would need to use only datatypes that are
> available everywhere.

No, the abstraction layer must have knowledge of the data types, so the 
current MySQL implementation can easily use DATETIME fields and is not 
limited to common features of "all" database systems.

> Again, happy to discuss or being corrected, but I think replacing the
> current integer storage with a string based version might be the most
> flexible solution and should be worth the effort (it doesn't seem to be
> to complicated).

Well, if the abstraction layer cannot support different data types for 
different database systems it is either seriously flawed or NoSQL 
databases will definitely not be supported.

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.

-- 
Kind regards / met vriendelijke groet,

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