[Dbix-class] InflateColumn::DateTime

Jess Robinson castaway at desert-island.demon.co.uk
Wed Jun 14 14:56:52 CEST 2006

On Thu, 8 Jun 2006, Dan Horne wrote:

>> On Behalf Of Matt S Trout=
>> Subject: Re: [Dbix-class] InflateColumn::DateTime
>> Christopher H. Laco wrote:
>>> Can someone give me a quick synopsis of how this works.
>>> It looks like it's always loaded, and only intervenes when it sees a
>>> column_info data_type of 'datetime'.
>> It's not always loaded, you have to ask for it. Yeah, all it does is
>> intervene in the case of a register_column call for a datetime.
> Actually, this is something that I've been meaning to raise, but I've been
> beaten to it. Oracle has no concept of a datetime data type, it just has
> date.
> Now, I could just declare date columns as datetime columns in the table
> class, but this seems to contravene the approach specified in the
> DBIx::Class::ResultSource doco:
> "Currently there is no standard set of values for the data_type. Use
> whatever your database supports."

Oops, missed this discussion. Yes, I wrote that bit of doc, since 
currently whatever you supply there is used by ->deploy to create the 
tables for you. This is because SQL::Translator, which is being used to 
create nifty SQL statements from the DBIC schema, also doesn't have any 
generic way of specifying types.

Way down on my list of things to fix in SQLT, is this particular problem. 
Ideally, parsed in type names will be represented internally as something 
nice and standard (like the list of ODBC type IDs that DBI docs list). 
After I get around to that, we should be able to set data_types in DBIC as 
the generic type, and fix the SQLT::DBIC parser accordingly.

i.e. add_column('mytimefield' => { data_type => 'date_and_time' ..  will 
output as datetime on mysql, date on oracle, and appropriate stuff for 
other DBs. It'll probably need an extra flag to say "this is a generic 
type" rather than a db specific one. This is one of the few things 
preventing us from being able to deploy the same schema onto many 
different database types.



More information about the Dbix-class mailing list