Meaning of column_info field names

My .02: You could, you could not, I don't think it matters
much in a  
project-wide sort of way. Though having method names
starting with  
underscores seems pretty ugly to me. Maybe, you could just
define  
#flags, #flags=, etc.? Though you certainly don't want to
define  
#type and #type=. Maybe some more specific names like
#mysql_flags,  
#mysql_type, ?

On Mar 30, 2006, at 1:45 PM, Paul DuBois wrote:

> Another question about driver-specific values in the
result from
> column_info.
>
> For the standard info attributes (name, precision,
scale, etc.),
> columninfo.rb sets things up so that you can access
them two ways:
>
> value = info["name"]
> info["name"] = value
>
> or:
>
> value = info.name
> info.name = value
>
>
> Question:  For driver-specific attributes in the MySQL
driver, I'm  
> setting
> up new keys in the info hash, as shown in the final
lines of this  
> code:
>
>     unique_key_flag =
MysqlField.const_get(:UNIQUE_KEY_FLAG)
>     multiple_key_flag =
MysqlField.const_get(:MULTIPLE_KEY_FLAG)
>     indexed = (unique_key_flag | multiple_key_flag)
>
>     # Note: Cannot get 'default' because
MysqlField.def is set
>     # only by mysql_list_fields()
>
>     res_handle.fetch_fields.each {|col|
>       retval << {
>                   # Standard Ruby DBI keys
>                   'name'        => col.name,
>                   #'sql_type'    => ???,
>                   #'type_name'   => ???,
>                   'precision'   => col.length,
>                   'scale'       => col.decimals,
>                   'nullable'    =>
!col.is_not_null?,
>                   'primary'     =>
col.is_pri_key?,
>                   'unique'      => ((col.flags
& unique_key_flag) ! 
> = 0) ||
>                                    col.is_pri_key?,
>                   'indexed'     => ((col.flags
& indexed) != 0) ||
>                                    col.is_pri_key?,
>                   # MySQL-specific keys (signified by
leading  
> underscore)
>                   '_type'       => col.type,
>                   '_length'     => col.length,
>                   '_max_length' => col.max_length,
>                   '_flags'      => col.flags
>                 }
>     }
>
>
> For consistency, should the driver also define methods
like _type,  
> _type=,
> _flags, _flags=, and so forth?
>
>
> _______________________________________________
> Ruby-dbi-next mailing list
> Ruby-dbi-nextrubyforge.org
> h
ttp://rubyforge.org/mailman/listinfo/ruby-dbi-next


Francis Hwang
http://fhwang.net/



_______________________________________________
Ruby-dbi-next mailing list
Ruby-dbi-nextrubyforge.org
h
ttp://rubyforge.org/mailman/listinfo/ruby-dbi-next

I agree that names such as mysql_flags, mysql_type would be
better as method
names.  Perhaps for consistency, we should adopt the
convention that
driver-specific column_info names should begin with mysql_
rather than just
underscore?  Then we'd have info["mysql_flags"]
and info.mysql_flags, which
is more consistent than info["_flags"] and
info.mysql_flags.


On 4/5/06 13:39, "Francis Hwang" <serafhwang.net> wrote:

> My .02: You could, you could not, I don't think it
matters much in a
> project-wide sort of way. Though having method names
starting with
> underscores seems pretty ugly to me. Maybe, you could
just define
> #flags, #flags=, etc.? Though you certainly don't want
to define
> #type and #type=. Maybe some more specific names like
#mysql_flags,
> #mysql_type, ?
> 
> On Mar 30, 2006, at 1:45 PM, Paul DuBois wrote:
> 
>> Another question about driver-specific values in
the result from
>> column_info.
>> 
>> For the standard info attributes (name, precision,
scale, etc.),
>> columninfo.rb sets things up so that you can access
them two ways:
>> 
>> value = info["name"]
>> info["name"] = value
>> 
>> or:
>> 
>> value = info.name
>> info.name = value
>> 
>> 
>> Question:  For driver-specific attributes in the
MySQL driver, I'm
>> setting
>> up new keys in the info hash, as shown in the final
lines of this
>> code:
>> 
>>     unique_key_flag =
MysqlField.const_get(:UNIQUE_KEY_FLAG)
>>     multiple_key_flag =
MysqlField.const_get(:MULTIPLE_KEY_FLAG)
>>     indexed = (unique_key_flag | multiple_key_flag)
>> 
>>     # Note: Cannot get 'default' because
MysqlField.def is set
>>     # only by mysql_list_fields()
>> 
>>     res_handle.fetch_fields.each {|col|
>>       retval << {
>>                   # Standard Ruby DBI keys
>>                   'name'        => col.name,
>>                   #'sql_type'    => ???,
>>                   #'type_name'   => ???,
>>                   'precision'   => col.length,
>>                   'scale'       =>
col.decimals,
>>                   'nullable'    =>
!col.is_not_null?,
>>                   'primary'     =>
col.is_pri_key?,
>>                   'unique'      => ((col.flags
& unique_key_flag) !
>> = 0) ||
>>                                    col.is_pri_key?,
>>                   'indexed'     => ((col.flags
& indexed) != 0) ||
>>                                    col.is_pri_key?,
>>                   # MySQL-specific keys (signified
by leading
>> underscore)
>>                   '_type'       => col.type,
>>                   '_length'     => col.length,
>>                   '_max_length' =>
col.max_length,
>>                   '_flags'      => col.flags
>>                 }
>>     }
>> 
>> 
>> For consistency, should the driver also define
methods like _type,
>> _type=,
>> _flags, _flags=, and so forth?
>> 
>> 
>> _______________________________________________
>> Ruby-dbi-next mailing list
>> Ruby-dbi-nextrubyforge.org
>> h
ttp://rubyforge.org/mailman/listinfo/ruby-dbi-next
> 
> 
> Francis Hwang
> http://fhwang.net/
> 
> 
> 
> _______________________________________________
> Ruby-dbi-next mailing list
> Ruby-dbi-nextrubyforge.org
> h
ttp://rubyforge.org/mailman/listinfo/ruby-dbi-next
> 


_______________________________________________
Ruby-dbi-next mailing list
Ruby-dbi-nextrubyforge.org
h
ttp://rubyforge.org/mailman/listinfo/ruby-dbi-next