List Info

Thread: Meaning of column_info field names




Meaning of column_info field names
user name
2006-04-07 04:25:04
I'll second that motion.  Or third, or wherever we are
now. 

Dan

--- Paul DuBois <paulkitebird.com> wrote:

> 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
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection
around 
http://mail.yahoo.com 
_______________________________________________
Ruby-dbi-next mailing list
Ruby-dbi-nextrubyforge.org
h
ttp://rubyforge.org/mailman/listinfo/ruby-dbi-next
Meaning of column_info field names
user name
2006-04-10 18:26:45
On Thursday 06 April 2006 10:25 pm, Daniel Berger wrote:
> I'll second that motion.  Or third, or wherever we are
> now. 

Me too.  


Kirk
_______________________________________________
Ruby-dbi-next mailing list
Ruby-dbi-nextrubyforge.org
h
ttp://rubyforge.org/mailman/listinfo/ruby-dbi-next
Meaning of column_info field names
user name
2006-04-11 20:31:14
Okay, based on the apparent concensus, I've made this
change:

  Mysql.rb. Renamed column_info attributes/methods:
  _type, _length, _max_length, _flags are now
  mysql_type, mysql_length, mysql_max_length, mysql_flags

This is also more consistent with the DB2 driver use of
db2_type as a driver-specific name.  An added plus. 


On 4/10/06 13:26, "Kirk Haines" <khainesenigo.com> wrote:

> On Thursday 06 April 2006 10:25 pm, Daniel Berger
wrote:
>> I'll second that motion.  Or third, or wherever we
are
>> now. 
> 
> Me too.  
> 
> 
> Kirk
> _______________________________________________
> 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
[1-3]

about | contact  Other archives ( Real Estate discussion Medical topics )