> What's "OP" ?
Original Poster - the person who started the thread.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "Ruby
on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com
Jordi Bunster wrote:
> On Nov 26, 2007, at 9:40 PM, Michael Koziarski wrote:
>
>>> I would argue this is not an issue of "most" or even "standard" --
>>> most
>>> code on the planet is probably written with camelCase names -- which
>>> doesn't seem to have much impact on Rails' opinion.
>>
>> T
On Nov 26, 2007, at 9:40 PM, Michael Koziarski wrote:
I would argue this is not an issue of "most" or even "standard" --
most
code on the planet is probably written with camelCase names -- which
doesn't seem to have much impact on Rails' opinion.
The real problem is that you *can't* retrieve
Michael Koziarski wrote:
>> I would argue this is not an issue of "most" or even "standard" -- most
>> code on the planet is probably written with camelCase names -- which
>> doesn't seem to have much impact on Rails' opinion.
>
> The real problem is that you *can't* retrieve that data again. Ra
> I would argue this is not an issue of "most" or even "standard" -- most
> code on the planet is probably written with camelCase names -- which
> doesn't seem to have much impact on Rails' opinion.
The real problem is that you *can't* retrieve that data again. Rails
needs to coerce those values
BTW everyone -- I appreciate the discussion, and the points being made.
Not convinced I'm wrong yet, but I do appreciate the time being taken to
read & respond.
-- gw
--
Posted via http://www.ruby-forum.com/.
--~--~-~--~~~---~--~~
You received this message bec
John Maenpaa wrote:
> The 1992 draft SQL standard (sorry, all I have handy at the moment)
> says "The s other than SECOND contain non-negative
> integer values, constrained by the natural rules for dates using the
> Gregorian calendar." This leaves it up to the Gregorian calendar,
> which doesn't
The 1992 draft SQL standard (sorry, all I have handy at the moment)
says "The s other than SECOND contain non-negative
integer values, constrained by the natural rules for dates using the
Gregorian calendar." This leaves it up to the Gregorian calendar,
which doesn't have a year zero, muc
On Nov 24, 2007 10:45 PM, Greg Willits <[EMAIL PROTECTED]>
wrote:
> If a (MySQL) database table declares a datetime field as NOT NULL with a
> default value of -00-00 00:00:00 and an empty value is submitted to
> that field via Rails, Rails complains that the field cannot be null. If
> a strin
DHH wrote:
>> What's the point of having different dbs if app frameworks reduce them
>> to some wimpy lowest common denominator.
>
> Why even bother with SQL, then :)? Why not just give every database
> their own query language that's designed just for them. There are
> other reasons than API to
> What's the point of having different dbs if app frameworks reduce them
> to some wimpy lowest common denominator.
Why even bother with SQL, then :)? Why not just give every database
their own query language that's designed just for them. There are
other reasons than API to pick different databa
Tim Connor wrote:
> Do we want to follow MYSQL, or any specific DB provider, practices,
> over ruby's, though? And/or the standards? (Don't honestly know what
> ANSI SQL has to say about -00-00).
Isn't that one of the reasons for choosing one database over
another--its support of different
Do we want to follow MYSQL, or any specific DB provider, practices,
over ruby's, though? And/or the standards? (Don't honestly know what
ANSI SQL has to say about -00-00).
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
Michael Koziarski wrote:
>> If I can override the behavior somehow, that would be fine with me too.
>> I can design around it in the future, but I would like the option if
>> it's possible.
>
> Unfortunately even if we did want to fix this, I'm not sure what the
> accessors could return:
>
>>> D
> > If you can find the trac tickets where this has been discussed and
> > perhaps when it was first introduced we could figure out what was
> > going on.
>
>
> http://dev.rubyonrails.org/ticket/2391
>
> If the answer is that this particular group of people have a binary view
> of dates, then wadd
Michael Koziarski wrote:
>> >> I don't follow what it is you're trying to achieve.
>>
>> Dang. Did it again. You wanted scenarios...
>
> No worries, sorry if I came across a little harsh.
Nah, I started it ;-)
> If you can find the trac tickets where this has been discussed and
> perhaps when
Tim Connor wrote:
> On Nov 24, 8:53 pm, Greg Willits <[EMAIL PROTECTED]>
> wrote:
>> A typical example would be a Date Due field where a valid date = when it
>> was done, a NULL value = not done yet that we know of, and a -00-00
>> value = it has been declared that it never will be done. Repor
On Nov 24, 8:53 pm, Greg Willits <[EMAIL PROTECTED]>
wrote:
> A typical example would be a Date Due field where a valid date = when it
> was done, a NULL value = not done yet that we know of, and a -00-00
> value = it has been declared that it never will be done. Reports for
> this data must b
A date field should contain only valid dates or be null. If you need a
third alternative, use a code/switch field or store your date in a
string. I don't believe there are any valid scenarios where storing
invalid dates in a date field is more appropriate than using a
separate code/switch
> >> I don't follow what it is you're trying to achieve.
>
> Dang. Did it again. You wanted scenarios...
No worries, sorry if I came across a little harsh.
If you can find the trac tickets where this has been discussed and
perhaps when it was first introduced we could figure out what was
going
Greg Willits wrote:
> Michael Koziarski wrote:
>> I don't follow what it is you're trying to achieve.
Dang. Did it again. You wanted scenarios...
A typical example would be a Date Due field where a valid date = when it
was done, a NULL value = not done yet that we know of, and a -00-00
va
Michael Koziarski wrote:
>> Rails is wrong in asserting that -00-00 is poor database design, and
>> Rails is wrong to prevent the value from being used.
>
> Your approach is wrong in attempting to generate discussion. Your
> attempt to make your point clear is wrong in that I don't follow w
> Rails is wrong in asserting that -00-00 is poor database design, and
> Rails is wrong to prevent the value from being used.
Your approach is wrong in attempting to generate discussion. Your
attempt to make your point clear is wrong in that I don't follow what
it is you're trying to achiev
23 matches
Mail list logo
