[Dbix-class] Calling all database champions

[John Napiorkowski]

--- Nathan Gray <kolibrie at graystudios.org> wrote:

> On Sat, May 26, 2007 at 02:22:44PM +0100, Matt S
> Trout wrote:
> > On Sat, May 26, 2007 at 08:30:29AM -0400, Jason
> Kohles wrote:
> > > On May 23, 2007, at 8:04 PM, Tom Lanyon wrote:
> > > >
> > > PostgreSQL has more than one timestamp type,
> which may show up in the  
> > > column_info as:
> > > 
> > > timestamp with time zone
> > > timestamp without time zone
> > > timestamp
> > > timestamptz
> > 
> > And none of those need special handling?
> > 
> > Peopl who champion a specific DB engine, how would
> this work for you?
> > 
> > I'm getting increasingly tempted to just sod it
> and apply jason's patch
> > when he sends out a test case or two for it and
> we'll see what happens.
> 
> Oracle also has several date types.  However, with
> PostgreSQL, setting
> the date format only affects display (supplying a
> date in any of the
> valid formats works).  In Oracle, setting the date
> format affects both
> display and parsing (a date supplied to the database
> must match the
> date format currently in effect).
> 
> To complicate matters further (or simplify,
> depending on your point of
> view), each Oracle date type format is set
> independently.  So setting
> the format for a 'date' does not affect the format
> for 'timestamp'.
> 
> Also, unfortunate for Perl's DateTime, the Oracle
> date types are named
> somewhat strangely.
> 
>   DATE                    # date and time
>   TIMESTAMP               # date and time with
> sub-second granularity
>   TIMESTAMP WITH TIMEZONE # timestamp with timezone
> information
> 
> In the DateTime::Format::Oracle module, 'parse_date'
> and
> 'parse_datetime' are synonymous, because an Oracle
> date really is a
> datetime.
> 
> I have hopes to implement methods 'parse_timestamp'
> and
> 'parse_timestamp_with_timezone'.
> 
> For Oracle, it would be best if DBIC date inflation
> looks at the full
> date datatype, such as:
> 
>   DATE
>   TIMESTAMP
>   TIMESTAMP WITH LOCAL TIMEZONE
>   TIMESTAMP WITH TIMEZONE
> 
> and looks for methods which are specific enough:
> 
>   parse_date
>   parse_timestamp
>   parse_timestamp_with_local_timezone
>   parse_timestamp_with_timezone
> 
> If there is no exact match, look for methods which
> are less specific:
> 
>   parse_timestamp_with_local_timezone
>   -> parse_timestamp_with_timezone
>   -> parse_timestamp
>   (-> parse_datetime)?
> 
> Each DateTime::Format::* class should then implement
> the generic
> 'parse_date' and 'parse_datetime' methods, as well
> as methods for each
> database specific date type.
> 
> -kolibrie

I worked with Oracle in a past life (but not with
DBIC) and have been bitten by various TimeDate related
issues.  Perhaps we can collaborate on the next
development cycle to work out a good API for this and
perhaps for other special column types?

One thing that I've used in Postgresql is it's ability
to map column types to tables so that once you define
a table you can use that as a compound type in another
table.  So this is something I'm putting time aside
for working on in the future.  

--john

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com