The revised patch submitted on #4748 broke the build, I'm looking to
sort out why.
Also note that this auto-test email didn't make it to rails-core because
it was too big (every test failed, so the resulting email was huge).
I'll patch my auto-testing script to truncate the email to no larger
%Q{empty_#{ column.sql_type rescue 'blob' }()}
else
case value
Marcel Molina Jr. wrote:
On Wed, Apr 26, 2006 at 02:28:50PM -0700, Michael A. Schoen wrote:
The revised patch submitted on #4748 broke the build, I'm looking to
sort out why.
Also note that th
Marcel Molina Jr. wrote:
On Wed, Apr 26, 2006 at 02:51:17PM -0700, Michael A. Schoen wrote:
Fixed by applying this 1-line patch. I've also updated ticket #4748.
Applied. Thanks.
marcel
Thanks! The auto-test should sent out it's all-clear in anot
Corey Donohoe wrote:
I currently have to support both postgres and oracle for work. I'd
like to use booleans but I ran into a wall when I found oracle didn't
support them. The fix was really small and I adopted the convention
of NUMERIC(1) being boolean. It also uses a similar approach as the
Marcel Molina Jr. wrote:
Just added a new frontbase adapter...
Which I think breaks because the require of 'frontbase' isn't rescued --
so if frontbase itself isn't installed, kaboom!
___
Rails-core mailing list
Rails-core@lists.rubyonrails.org
htt
Marcel Molina Jr. wrote:
Thanks again for setting up this CI for Oracle Michael. Very cool.
/me looks squinty eyed at all the other proprietary adapter developers who
haven't setup CI yet
I'm happy to share the script I'm using to do the automated testing...
__
Michael Schoen wrote:
"marcel" has kicked AR/Oracle while it was down...
I think you fixed the actual frontbase problem, it's failing now for
some other reason -- I'm looking into it.
___
Rails-core mailing list
Rails-core@lists.rubyonrails.org
htt
Michael A. Schoen wrote:
Michael Schoen wrote:
"marcel" has kicked AR/Oracle while it was down...
I think you fixed the actual frontbase problem, it's failing now for
some other reason -- I'm looking into it.
Hmm, it is still something about frontbase that's bre
Michael A. Schoen wrote:
Michael A. Schoen wrote:
Michael Schoen wrote:
"marcel" has kicked AR/Oracle while it was down...
I think you fixed the actual frontbase problem, it's failing now for
some other reason -- I'm looking into it.
Hmm, it is still something ab
Ignore this -- my DBA reset my test database last night. A happy message
will come out after the next checkin.
Michael Schoen wrote:
"marcel" made AR/Oracle cry...
http://dev.rubyonrails.org/changeset/4332
r4332 | marcel
This can be fixed by enhancing the test to support Oracle's sql type for
integer, which is NUMBER(38), but this test also exposed a difference in
how the Oracle adapter is handling sql_type, and I'd like to just fix that.
I'll have a patch submitted by tomorrow that'll fix this.
Michael Schoen
Corey Donohoe wrote:
*POKE*
Any chance of getting this applied to trunk? Michael have you had the
chance to look over this or do you see any reason to keep this from
going in?
I'm in the process of combining this patch with another fix. Should have
it posted tonight.
___
Michael A. Schoen wrote:
Corey Donohoe wrote:
*POKE*
Any chance of getting this applied to trunk? Michael have you had the
chance to look over this or do you see any reason to keep this from
going in?
I'm in the process of combining this patch with another fix. Should have
it p
Marcel Molina Jr. wrote:
On Sun, May 14, 2006 at 11:41:43AM -0700, Michael Schoen wrote:
"marcel" made AR/Oracle cry...
http://dev.rubyonrails.org/changeset/4340
r4340 | marcel | 2006-05-14 11:37:22 -0700 (Sun, 14 May 2006
Michael Schoen wrote:
"david" made AR/Oracle cry...
http://dev.rubyonrails.org/changeset/4354
Issue here is just that :first isn't returning a specific record,
there's no default order by for Oracle. Can you fix by changing this to
either #find(id), or add :order => "id"?
So I've finally bitten the bullet and patched the AR Oracle adapter to
use real OCI bind variables. This has a measurable impact on the client
side, and a huge impact on a high volume Oracle server due to the sql
hard parses that it saves.
The implementation involves some funky regex's on the
Blair Zajac wrote:
To work around lack of bind variables, our Oracle DBA has enabled cursor
sharing, which is an extra pass that Oracle does over the SQL. So it'll
take two separate SQL statements, say
Yep, that's what we're doing right now in production as well. The
biggest issues are: a) i
Michael Koziarski wrote:
If instead of doing the value interpolation immediately, we could hold
off and pass the full sql string down to the adapter.
["FULL SQL STRING", bunch, of, values]
Would be much nicer, but I wasn't sure how to even approach that, given
how frequently the sql is manipu
Jeremy Kemper wrote:
2. Do other db's support a similar concept with a similar benefit?
Should this functionality be implemented at a higher level (ie., in
the abstract adapter) to make it usable for other dbs?
Yes: the native postgres bindings support bind variables. In any case,
we can mov
Michael A. Schoen wrote:
Michael Koziarski wrote:
If instead of doing the value interpolation immediately, we could hold
off and pass the full sql string down to the adapter.
["FULL SQL STRING", bunch, of, values]
Would be much nicer, but I wasn't sure how to even approach t
Michael A. Schoen wrote:
IOW, I'd rather that this patch NOT be applied -- in fact I think my
approach should be looked at with good humor, and then thrown away, in
favor of representing an executable sql statement as an array of
statement and bind values. With each connection adapter han
Michael A. Schoen wrote:
Michael A. Schoen wrote:
IOW, I'd rather that this patch NOT be applied -- in fact I think my
approach should be looked at with good humor, and then thrown away, in
favor of representing an executable sql statement as an array of
statement and bind values. With
Blair Zajac wrote:
Turns out that Oracle may return a Date object even if the SQL column is
a timestamp if the hours, minutes and seconds are all 0.
I've proposed a different immediate fix, patch in:
http://dev.rubyonrails.org/ticket/5294
taking the approach that given a field type of
Blair Zajac wrote:
Do you have any URLs describing why we have to assume a datetime in Oracle?
It's because Oracle doesn't have a date-only field type, DATE is
actually a datetime. The original author made an attempt to be smart
about whether you'd get back a Ruby Date or Time object, but I'm
Wilson Bilkovich wrote:
If the Oracle adapter is going to assume a particular type for DATE
fields (and I think it should, for sure), shouldn't it default to one
that can handle the full range of dates that the Oracle DATE type can
represent?
I know I've seen Rails apps that store dates prior to
Michael A. Schoen wrote:
I've proposed a different immediate fix, patch in:
http://dev.rubyonrails.org/ticket/5294
taking the approach that given a field type of datetime (which is what
we have to assume within Oracle), it should always at least format as a
datetime, even if a parti
Michael Koziarski wrote:
> #xmlschema was aliased to #to_s for Date, which seems odd; making it
> work like Time#xmlschema seems to make more sense.
Can I get a commit on this? Any issues?
The .to_s was deliberate as the iso 8601 format for Dates without Time is
CCYY-MM-DD which is the same ou
Coda Hale wrote:
Well, I'm working with MySQL, which returns records by order of
primary key. (I think.) Does anyone know of any Rails-supported RDBMS
which doesn't do this?
Oracle doesn't.
___
Rails-core mailing list
Rails-core@lists.rubyonrails.org
Michael Koziarski wrote:
That's a strange change to embed in an oracle fix? Was it
intentional david? Michael?
http://dev.rubyonrails.org/changeset/4552
Agreed, that wasn't in my patch. I presume another patch from somebody
else got applied by mistake?
___
Sorry for the spam folks -- I had turned off my autotesting script for a
bit while I hacked away, to avoid conflicts in my test db. Just turned
it back on, and it got caught up.
I'll have a patch submitted shortly to get it back into shape.
___
Rails
Michael A. Schoen wrote:
I'll have a patch submitted shortly to get it back into shape.
http://dev.rubyonrails.org/ticket/5635
___
Rails-core mailing list
Rails-core@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/
Michael Schoen wrote:
"bitsweat" has given AR/Oracle some love, but it's still unhappy...
http://dev.rubyonrails.org/changeset/4574
Thanks for applying the patch. One diff (below) was left out though,
which is why the test is still failing. Using find_every().first skips
the unnecessary (in
Michael Schoen wrote:
"bitsweat" has given AR/Oracle some love, but it's still unhappy...
http://dev.rubyonrails.org/changeset/4578
Ugh. So the actual problem is fixed now (thanks), the test is failing
because my db server is running a bit slow, and the 1s sleep in the
locking tests wasn't s
Jeremy Kemper wrote:
So, Tom, you looking to be a bug magnet? ;)
Tom: let me know if you'd like a copy of the script I use to test
against the Oracle adapter after every checkin. It's not very fancy, but
it does a good job spamming rails-core when stuff breaks. ;-)
_
So, I'm personally cool with this change (patch from #5454, applied in
[4596]), and I'll make it work for Oracle tomorrow.
But just wondering if folks considered the performance impact of the
change? From a simple test it seems that BigDecimal math is about twice
as slow as using Floats.
Michael Koziarski wrote:
It appears to still use floats for 'float' columns, does oracle not
have one?
Not really. Oracle uses "NUMBER" for all numeric columns. There's also a
"FLOAT" type, but it's not typically used (and it's effectively the same
as NUMBER).
In my patch to make this wor
Robin H. Johnson wrote:
However more significantly, unless you mis-read the patch, :float is NOT
replaced with :decimal. It's merely supplemented. Using :float still
gets you the same old behavior in Rails.
Oracle doesn't really have a FLOAT or DECIMAL datatype, it's all NUMBER.
I'll get the O
Patched:
http://dev.rubyonrails.org/ticket/5667
Michael Schoen wrote:
"bitsweat" made AR/Oracle cry...
http://dev.rubyonrails.org/changeset/4596
r4596 | bitsweat | 2006-07-08 13:35:56 -0700 (Sat, 08 Jul 2006) | 11
Michael Schoen wrote:
"marcel" made AR/Oracle cry...
http://dev.rubyonrails.org/changeset/4608
r4608 | marcel | 2006-07-12 20:23:39 -0700 (Wed, 12 Jul 2006) | 1 line
Customize default BigDecimal formatting. [EMAIL PROTECTE
This AR test is still broken, can somebody apply the patch below?
Michael Schoen wrote:
"marcel" made AR/Oracle cry...
http://dev.rubyonrails.org/changeset/4608
r4608 | marcel | 2006-07-12 20:23:39 -0700 (Wed, 12 Jul 2006)
I know this was discussed a while back, but I couldn't find the thread.
Issue is that has_one associations don't cache nils, whereas has_many do
cache the empty array.
Causes a big performance issue when you do things like:
class People < ActiveRecord::Base
has_one :thing
end
Person
Anyone?
Michael A. Schoen wrote:
I know this was discussed a while back, but I couldn't find the thread.
Issue is that has_one associations don't cache nils, whereas has_many do
cache the empty array.
Causes a big performance issue when you do things like:
class People <
Michael Schoen wrote:
"bitsweat" made AR/Oracle cry...
http://dev.rubyonrails.org/changeset/4690
r4690 | bitsweat | 2006-08-06 12:23:40 -0700 (Sun, 06 Aug 2006) | 1 line
Don't save has_one associations unnecessarily. Close
Just posted a small patch for AWS, enabling support for nillable fields
in the generated WSDLs (about which some clients, such as .NET, are anal).
http://dev.rubyonrails.org/ticket/5748
Is Kent Sibilev around to give his stamp of approval?
__
David Heinemeier Hansson wrote:
So...is this intentional? Would core be open to a patch that allowed AR
to differentiate between "nil -- this association needs to be loaded"
and "nil -- the target is actually nil"?
Yes, please do investigate something better. I believe it was done
simply becaus
Is someone core-ish able to ping me on the security issue?
[EMAIL PROTECTED]
AIM: mschoen71
YIM: michael_schoen
Thanks!
___
Rails-core mailing list
Rails-core@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/
Extends the change in [4721] to handle associations loaded eagerly.
http://dev.rubyonrails.org/ticket/5787
___
Rails-core mailing list
Rails-core@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails-core
47 matches
Mail list logo
