[FLOW3-general] DateTime limited to Unix timestamp?

[Michael Sauter]

Hi,

On 08.10.10 12:51, Jigal van Hemert wrote:
> 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.

Question: What good is the specific datatype if you have a string 
representation in the abstraction?
The only thing you gain is that you could use the operations on it when 
you avoid the querying API and use raw queries instead. But then you 
lose the abstraction provided by FLOW3, and porting gets harder.
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 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?


To sum it up, while I'm all in for storing data in the appropriate 
datatype, you need to consider that
a) you would have to introduce an API for it to make it really useful 
(which then will be hard to implement for other backends) or
b) if you don't create new API's, then you don't gain much (anything?) 
by using a specific storage.

So yes, we could create 2 different SQL backends, one with a string 
(for, e.g. the default SQLLite db which does not have a specific 
datetime datatype) and one with a datetime storage for MySQL and so on 
(I guess that would be DATETIME then?). But this alone does not help 
much. I think the more important question is: do we want to have an 
abstract way of dealing with date/time or not? And if so, how?

~michael