Rails seems to have a type system of sorts that is used by ActiveRecord and ActiveView. For example, date objects are understood directly by ActiveRecord and have special input methods defined in ActiveView, which can be implicitly invoked in forms. I don''t think, however, that the SQL types available actually represent the entirety of types that are used by the application developer. Types that would be of interest to me include types for working with currency, restricted dates, times, choices (where the value is an index into a choice table), other types of simple selections besides boolean checkboxes (maybe two or three choice radio buttons), phone numbers, postal codes, weights and measures, etc. I think it be desirably to localize as much functionality as possible within a type, rather than within an input form. So, for example, if a phone number must have a certain number of digits, then the supporting type should be able to generate an appropriate error if an attempt at input is incorrectly formatted (whether through javascript or at the server--either should be possible). I can imagine using a type system like this for generating ouput as well. A type might have a method describing the type of formatting that should be applied by default in a table cell (left, right, center justification, for example), or an associated CSS tag that should be applied (a financial "balance" type, for example might render itself using a CSS tag to distinguish positive/negative balances). I would greatly appreciate hearing any thoughts anyone has on this subject. Thanks, Bob
On Wed, 8 Dec 2004, Bob Sidebotham wrote:> I don''t think, however, that the SQL types available actually > represent the entirety of types that are used by the application > developer....They don''t even represent all of the types available for columns in the database. And in fact, they simply can''t, since databases such as PostgreSQL allow user-defined types.> I think it be desirably to localize as much functionality as possible > within a type, rather than within an input form. So, for example, if a > phone number must have a certain number of digits, then the supporting > type should be able to generate an appropriate error if an attempt at > input is incorrectly formatted (whether through javascript or at the > server--either should be possible).That''s quite interesting. There''s a bit of a split here for me for validation; on the one hand, I''ve already got the database doing validation of the data, why do I want it happening again in Ruby? But then again, there are other kinds of validation that are much easier to do in Ruby code than in the DB. And then again, it can be more user-friendly to validate on the client side, before a form is posted. So it seems to me that in an ideal world you want the ability to specify different sorts of validation: 1. Validation information passed to the web browser (implemented as, e.g., form size limits or Javascript that programatically checks values). 2. Validation done in Ruby. This is particularly important for things that may be hard to verify from the database, such as whether your credit card company will allow a charge for that card. 3. Validation information from the database. The ideal thing here is that if you know what your database constraints are, you''d like efficiently to have the database do the validation itself rather than write that validation code a second time in Ruby. I would also want user-defined types in Ruby to be able to be able to do the appropriate thing as far as getting these types to and from the database, when they exist there. So if I, say, generate a new PostgreSQL type "duration", and one possible represenation of it is as a timestamp with time zone and an interval (e.g., "2003-07-12 13:45:22.0007638-04, 81293 min"), the Ruby object representing a value of that type could generate the appropriate representation for the database code, and interpret the representations that come back from the database. cjs -- Curt Sampson <cjs-gHs2Wiolu3leoWH0uzbU5w@public.gmane.org> +81 90 7737 2974 http://www.NetBSD.org Make up enjoying your city life...produced by BIC CAMERA
> That''s quite interesting. There''s a bit of a split here for me for > validation; on the one hand, I''ve already got the database doing > validation of the data, why do I want it happening again in Ruby? But > then again, there are other kinds of validation that are much easier > to do in Ruby code than in the DB. And then again, it can be more > user-friendly to validate on the client side, before a form is posted.I don''t know anything about database validation of data (I''ve only used MySQL which has not had that functionality in the past--it may or may not now, I''m not sure). What sort of errors do you get back? Do you have to write error interpretation code, anyway, if you want to give a sensible error to the user. As opposed to, say, "bad value", I''d rather be able to emit messages that are as specific and user friendly as possible.> So it seems to me that in an ideal world you want the ability to specify > different sorts of validation: > > 1. Validation information passed to the web browser (implemented as, > e.g., form size limits or Javascript that programatically checks > values).Actually I don''t really care that much for client-side validation in Javascript. It tends to lead to bloated code (possibly mitgated by including the javascript code from another file) and yet another layer of integrity checks. I''d be happy with server-side only, with easy-to-use generic form checking. The main reason I mentioned it in the first place is that I wouldn''t want to exclude this possibility.> 2. Validation done in Ruby. This is particularly important for > things that may be hard to verify from the database, such as whether > your credit card company will allow a charge for that card.And for those of us who don''t use constraints in the database, I''d like to be able to specify everything in the ruby code.> 3. Validation information from the database. The ideal thing here > is that if you know what your database constraints are, you''d like > efficiently to have the database do the validation itself rather > than write that validation code a second time in Ruby.But you''d still like an interface that made this transparent--that is, it shouldn''t matter whether the error was generated by the database or by the ruby code, from above, it should just look like a type error--you shouldn''t need specialized code in your controllers to deal with these database errors.> I would also want user-defined types in Ruby to be able to be able to > do the appropriate thing as far as getting these types to and from the > database, when they exist there. So if I, say, generate a new PostgreSQL > type "duration", and one possible represenation of it is as a timestamp > with time zone and an interval (e.g., "2003-07-12 13:45:22.0007638-04, > 81293 min"), the Ruby object representing a value of that type could > generate the appropriate representation for the database code, and > interpret the representations that come back from the database.Absolutely--that should have been on my list. And of course, it''s how the date type works in AR now. And like a date type, there could be multiple external representations. As an aside, if you specify the types for all the columns in a database table, then you''re getting to the point where you could generate the database schema from the Ruby record definitions. There''s a Perl library--Alzabo--that does just that.As an option, this might be attractive to some. It''s also potentially dangerous, so I''m not actually suggesting going there. Bob
On 9.12.2004, at 05:35, Curt Sampson wrote:> I would also want user-defined types in Ruby to be able to be able to > do the appropriate thing as far as getting these types to and from the > database, when they exist there. So if I, say, generate a new > PostgreSQL > type "duration", and one possible represenation of it is as a timestamp > with time zone and an interval (e.g., "2003-07-12 13:45:22.0007638-04, > 81293 min"), the Ruby object representing a value of that type could > generate the appropriate representation for the database code, and > interpret the representations that come back from the database.I''m also very interested in the ''interval'' datatype. I''m writing an application that needs to store time intervals and the lack of support for them would solely be enough for me to choose PG instead of MySQL. However, as long as there''s no equivalent type on the ruby side, it doesn''t take me that far. So what would it take to get: - a working mapping for ''interval'' (or whatever) datatype - a form helper that would understand that type and produce the input widgets as specified? I''m willing to commit this myself, I just need a few pointers on where to start from. //jarkko> > cjs > -- > Curt Sampson <cjs-gHs2Wiolu3leoWH0uzbU5w@public.gmane.org> +81 90 7737 2974 > http://www.NetBSD.org > Make up enjoying your city life...produced by BIC CAMERA > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- Jarkko Laine http://jlaine.net _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
On Thu, Dec 09, 2004 at 11:03:15AM +0200, Jarkko Laine wrote:> > I''m also very interested in the ''interval'' datatype. I''m writing an > application that needs to store time intervals and the lack of support > for them would solely be enough for me to choose PG instead of MySQL. > However, as long as there''s no equivalent type on the ruby side, it > doesn''t take me that far. So what would it take to get: > - a working mapping for ''interval'' (or whatever) datatype > - a form helper that would understand that type and produce the input > widgets as specified? > > I''m willing to commit this myself, I just need a few pointers on where > to start from. > > //jarkkoI''m currently porting an application to rails where I utilize intervals (as the run time of a movie). Right now I''ve just got a Ruby class that turns the string (eg "01:00:00") given from the database into the number of seconds (since that''s all I really need). I also opened up Object::Time and added the ability to + one of my Intervals (just for convenience). What Ruby type are you thinking you''d want pg''s interval mapped to? -Scott