Skip Menu |

This queue is for tickets about the SQL-Translator CPAN distribution.

Report information
The Basics
Id: 20919
Status: resolved
Priority: 0/
Queue: SQL-Translator
People
Owner: cpan [...] desert-island.me.uk
Requestors: cpan [...] desert-island.me.uk
Cc:
AdminCc:
Bug Information
Severity: Wishlist
Broken in: 0.08_01
Fixed in: (no value)

History Show all quoted text
  Wed Aug 09 16:12:18 2006 cpan [...] desert-island.me.uk - Ticket created
Subject: Generic sql types
Currently each parser stores its own db-specific data types into the schema it creates, and each producer tries to guess what to turn those types into. A better idea is to have the parsers store generic types, where possible, into an "sql_type" which will contain one of DBIs SQL_TYPE constants, and store the parser specific types in "data_type" as before. Producers can then choose to output the generic type in their own way, or use the original type information.
  Wed Aug 09 16:13:18 2006 cpan [...] desert-island.me.uk - Given to JROBINSON
  Thu Sep 21 07:40:00 2006 ash_rtcpan [...] firemirror.com - Correspondence added
On Wed Aug 09 16:12:18 2006, JROBINSON wrote: Show quoted text
> Currently each parser stores its own db-specific data types into the > schema it creates, and each producer tries to guess what to turn those > types into. > > A better idea is to have the parsers store generic types, where > possible, into an "sql_type" which will contain one of DBIs > SQL_TYPE constants, and store the parser specific types in "data_type" > as before. Producers can then choose to output the generic type in > their own way, or use the original type information.
Also - some method of warning about unknown types would be nice, that way I wont spend 15 mins looking at 'datatime' going What? Why aren't you working......
  Thu Sep 21 07:40:01 2006 The RT System itself - Status changed from 'new' to 'open'
  Thu Dec 02 06:40:15 2010 ribasushi [...] leporine.io - Correspondence added
On Wed Aug 09 16:12:18 2006, JROBINSON wrote: Show quoted text
> Currently each parser stores its own db-specific data types into the > schema it creates, and each producer tries to guess what to turn those > types into. > > A better idea is to have the parsers store generic types, where > possible, into an "sql_type" which will contain one of DBIs > SQL_TYPE constants, and store the parser specific types in "data_type" > as before. Producers can then choose to output the generic type in > their own way, or use the original type information.
Get on arcanez to make sure they do not fuck it up in SQLT2. There seems to be no consensus how to do it properly, poke folks in #sql-translator with ideas.
  Thu Dec 02 06:40:52 2010 ribasushi [...] leporine.io - Correspondence added
Deferred to sqlt2.
  Thu Dec 02 06:40:53 2010 ribasushi [...] leporine.io - Status changed from 'open' to 'resolved'