On May 4, 11:58 am, John W Higgins <[email protected]> wrote: > Jeremy, > > I just pulled Sequel 3.0 and noticed that there seems to be an issue with > the type_literal handling of a text column. > > For example > > FIREBIRD_DB.create_table! :test6 do > primary_key :xid > blob :val > String :val2 > varchar :val3, :size=>200 > text :val4 > end > > inside the firebird spec fails on the text column because it tries to create > the table as > > CREATE TABLE TEST6 (XID integer PRIMARY KEY , VAL blob, VAL2 varchar(255), > VAL3 varchar(200), VAL4 text) > > which fails on the text column because it needs to be BLOB SUBTYPE TEXT > > So that led me to type_literal_generic_string which apparantly is the new > method of altering types (as I've noticed this is the same within > PostgreSQL). The problem seems to be that the call flow starts with > type_literal which then decides whether to fall into type_literal_generic or > type_literal_specific. Since "text" is considered specific we never get to > type_literal_generic_string via type_literal_generic and therefore "text" > gets pulled through and thus fails. > > I think the PostgreSQL adapter has the same issue but text is a valid type > for it and therefore it passes the spec. The adapter would seem to want to > change it to a bytea column but I can't see how it would get there unless > there is another layer within the PostgreSQL adapter that the Firebird > adapter doesn't have. > > Any ideas on the best route to patch this up? I apologize for not having > tested a release candidate prior to the 3.0 release.
Sequel is operating as designed in this case. There are two ways that Sequel supports types: generic and specific. Generic: FIREBIRD_DB.create_table! :test6 do primary_key :xid File :val String :val2 String :val3, :size=>200 String :val4, :text=>true end Specific: FIREBIRD_DB.create_table! :test6 do primary_key :xid blob :val varchar :val2 varchar :val3, :size=>200 column :val4, "BLOB SUBTYPE TEXT" end When using generic types, Sequel will use the most appropriate type for your database. When using the specific types, Sequel will use the value as-is. For historical reasons, Sequel does translate double to double precision even when using specific types, and will use a specific size of 255 for varchar if no size is given, but that's it in terms of translation. Basically, if you want type translation, use generic types. If you use specific types, you are in database specific territory, so you should use the type specific for your database. There will not be any further type translation added to the specific type layer, beyond that which is already there for historical reasons. The change to the Firebird adapter was mentioned in the 3.0.0 release notes. I'm sorry I didn't mention it to you personally. Other than that, is the Firebird adapter working fine in 3.0.0? I had made some nontrivial changes to it since 2.12.0, so hopefully I didn't unintentionally break something. Thanks, Jeremy --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sequel-talk" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/sequel-talk?hl=en -~----------~----~----~----~------~----~------~--~---
