Ok, the first patch I mentioned on Monday has been submitted:
http://dev.rubyonrails.org/ticket/1784
This allows synonyms in Oracle to work seamlessly, same as a normal
table. The patch includes a test. This is my first patch, so please
provide any feedback.
Next up is the enhancement to handle sequences per table, as in
{#table_name}_seq
My preference would be to actually just change the behavior, to expect
sequences per table, rather than using rails_sequence -- this seems to
be what most people want, and the comments seem to indicate that the
initial implementation using rails_sequence was put in because they
couldn''t get the other approach to work.
So, are folks ok with that? It will "break" everyone currently using
Oracle, but the fix is really easy -- just create the missing synonyms.
If that''s not ok, I could make it a configuration option, though
I''d
then prefer that the new approach be the default.
Opinions? Ideally I''d like to get an approach for handling this change
approved by DHH, etc, before I code it up.
Just changing the behaviour would be better for me, but I''m not in production on Oracle, so it''s a relatively trivial change for me. I guess folks in production might find that more difficult. On 7/20/05, Michael Schoen <schoenm-ihVZJaRskl1bRRN4PJnoQQ@public.gmane.org> wrote:> Ok, the first patch I mentioned on Monday has been submitted: > > http://dev.rubyonrails.org/ticket/1784 > > This allows synonyms in Oracle to work seamlessly, same as a normal > table. The patch includes a test. This is my first patch, so please > provide any feedback. > > Next up is the enhancement to handle sequences per table, as in > > {#table_name}_seq > > My preference would be to actually just change the behavior, to expect > sequences per table, rather than using rails_sequence -- this seems to > be what most people want, and the comments seem to indicate that the > initial implementation using rails_sequence was put in because they > couldn''t get the other approach to work. > > So, are folks ok with that? It will "break" everyone currently using > Oracle, but the fix is really easy -- just create the missing synonyms. > > If that''s not ok, I could make it a configuration option, though I''d > then prefer that the new approach be the default. > > Opinions? Ideally I''d like to get an approach for handling this change > approved by DHH, etc, before I code it up. > > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
On Jul 20, 2005, at 12:49 PM, Michael Schoen wrote:> My preference would be to actually just change the behavior, to > expect sequences per table, rather than using rails_sequence -- > this seems to be what most people want, and the comments seem to > indicate that the initial implementation using rails_sequence was > put in because they couldn''t get the other approach to work. > > So, are folks ok with that? It will "break" everyone currently > using Oracle, but the fix is really easy -- just create the missing > synonyms.This sounds good and I agree that it should be the default. jeremy
On 7/20/05, Michael Schoen <schoenm-ihVZJaRskl1bRRN4PJnoQQ@public.gmane.org> wrote:> Next up is the enhancement to handle sequences per table, as in > > {#table_name}_seq >There really shouldn''t be a need to dump the original way it was done. While 90%+ of systems probably work with the standard you are describing (or something close to that) - there really should be a need to make it a forced issue (we are using ruby aren''t we :) ). I would say that this shouldn''t be done at the Oracle adapter level - this is really an AbstractAdapter addition because there are multiple databases this could affect, Oracle and Postgresql (to a lesser extent) at the mininum. That really doesn''t change how it''s done though to a large degree. My thought would be that we have a hash of strings which are keyed with table names and have values of the sequence name for the table in question. The developer could get names into the hash via any of the three following mechanisms 1) The ability for the user to enter a value into the hash via a mechanism similar to table names or primary key names, something like set_generator_name in the model. 2) The ability to add a generic "pattern" that can be used by the adapter to create the sequence based off the table name within the environment variables. 3) A adapter level default pattern if nothing else is present. This would really give the best of all options to everyone. However, the situation would get a little muddy as to the Oracle adapter concerning mechanisms 2 and 3 - which would get filled in for each, is {#table_name}_seq the adapter default or is rails_sequence. I would guess it''s something like {#table_name}_seq with a strong note in the changelog/readme file for backwards compatability that an environment variable would need to be set for the use of existing systems with "rails_sequence" (remember you don''t have to do any substitutions in a pattern for it to still be a pattern). I would setup the code along the lines of sequence_name = @sequence_names[table_name] || evaluate_pattern(table_name, environment[''pattern'']) || evaluate_default_pattern(table_name) Each adapter would have an evaluate_default_pattern method which would hold the default pattern to be used for that adapter. To make it quicker I would set @sequence_names[table_name] within either evaluate_pattern or evaluate_default_pattern so that the method calls would only occur one time for each table. This would eliminate the overhead of the pattern matching as well as it wouldn''t be done with each call. I just can''t get my head around getting access to the environment variable within the abstractadapter or getting the set_generator_name value pushed down to the abstract adapter either. I''m sure they are straight forward but my brain isn''t working quite as well as I would like these days :) Sorry if I was long winded - my mind spews at times..... -- John W Higgins wishdev-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
On 7/20/05, John Higgins <wishdev-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> On 7/20/05, Michael Schoen <schoenm-ihVZJaRskl1bRRN4PJnoQQ@public.gmane.org> wrote: > > Next up is the enhancement to handle sequences per table, as in > > > > {#table_name}_seq > > > > There really shouldn''t be a need to dump the original way it was done. > While 90%+ of systems probably work with the standard you are > describing (or something close to that) - there really should be a > need to make it a forced issue (we are using ruby aren''t we :) ).The Postgres adapter already uses this convention for sequence names...
Presuming it works for most folks, I''ve gone ahead and submitted the
patch.
http://dev.rubyonrails.org/ticket/1787
This is the non-backwards-compatible version that uses #{table_name}_seq
as the sequence name.
Corey Lawson wrote:> On 7/20/05, John Higgins
<wishdev-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>There really shouldn''t be a need to dump the original way it
was done.
>>While 90%+ of systems probably work with the standard you are
>>describing (or something close to that) - there really should be a
>>need to make it a forced issue (we are using ruby aren''t we :)
).
>
> The Postgres adapter already uses this convention for sequence names...
Yep, and I actually copied the approach from the Postgres adapter.
I like John''s idea, or, less complicated, at least the ability to do
set_sequence_name :my_custom_seq
in the model. But I don''t know how to do that. Any takers?
> > Yep, and I actually copied the approach from the Postgres adapter. > > I like John''s idea, or, less complicated, at least the ability to do > > set_sequence_name :my_custom_seq > > in the model. But I don''t know how to do that. Any takers?Which part of it don''t you know how to do... the adding of set_sequence_name ? or the actual setting of the sequence? _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
>> I like John''s idea, or, less complicated, at least the ability to do >> >> set_sequence_name :my_custom_seq >> >> in the model. But I don''t know how to do that. Any takers? > > Which part of it don''t you know how to do... > > the adding of set_sequence_name ? > > or the actual setting of the sequence?Both I guess. I mean I can follow the model of how set_table_name is done, but I''m not sure that''s the right approach, given that "sequence_name" is only relevant for Oracle and sort of Postgres. Assuming DHH, et al, are ok with an ActiveRecord attribute that''s not relevant for all dbs, my real obstacle would be figuring out the right/best way to make it available within the adapter. I could probably muddle through, but I don''t have a clear enough understanding of how the components (AR::B, Connection, Adapdter) all hook together to do it cleanly. Any advice?
Personally, the seq patch is exactly how it should be done. Ive been an oracle DBA for 15 years, and Have never come upon an instance that sequences were not implemented that way. As far as forcing the issue, granted we are using ruby, but rails semi "forcrs" us to do things certain ways for tablenames etc whats wrong with doing it this way? it really only effects oracle users I think, and they are used to doing it like this. OT: Is there any listing or docs that shows some of the "gotchas" from using different db types? Sam On 7/20/05, Michael Schoen <schoenm-ihVZJaRskl1bRRN4PJnoQQ@public.gmane.org> wrote:> >> I like John''s idea, or, less complicated, at least the ability to do > >> > >> set_sequence_name :my_custom_seq > >> > >> in the model. But I don''t know how to do that. Any takers? > > > > Which part of it don''t you know how to do... > > > > the adding of set_sequence_name ? > > > > or the actual setting of the sequence? > > Both I guess. I mean I can follow the model of how set_table_name is > done, but I''m not sure that''s the right approach, given that > "sequence_name" is only relevant for Oracle and sort of Postgres. > > Assuming DHH, et al, are ok with an ActiveRecord attribute that''s not > relevant for all dbs, my real obstacle would be figuring out the > right/best way to make it available within the adapter. I could probably > muddle through, but I don''t have a clear enough understanding of how the > components (AR::B, Connection, Adapdter) all hook together to do it cleanly. > > Any advice? > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
On 7/21/05, Sam Mayes <codeslave-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> Personally, the seq patch is exactly how it should be done. Ive been > an oracle DBA for 15 years, and Have never come upon an instance that > sequences were not implemented that way. As far as forcing the issue, > granted we are using ruby, but rails semi "forcrs" us to do things > certain ways for tablenames etc whats wrong with doing it this way? it > really only effects oracle users I think, and they are used to doing > it like this.You probably are 100% correct in that every known Oracle standard would be #{table_name}_seq but there are ALWAYS edge cases and I just think that the small amount of code required for the flexibility would be well worth it. As much as Oracle has a standard Postgresql is even more standardized when it comes to this stuff because of the SERIAL datatype which will create the generator for you when you define a column of that type in your table. Yet, about 2 weeks ago there was a question on the list about modifying a generator name for a Postgresql table in Rails. The questions will always come and I''d rather see Rails just deal with it then hide. The biggest complaint about AR is it''s inflexibility in some edge cases. Why not just put one of those cases away? I''d be more then happy to write the patch - like I said yesterday there''s just a couple of small blocking concepts that my mind isn''t working around right now.... -- John W Higgins wishdev-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
> > Personally, the seq patch is exactly how it should be done. Ive > > been an oracle DBA for 15 years, and Have never come upon an > > instance that sequences were not implemented that way. As far as > > forcing the issue, granted we are using ruby, but rails semi > > "forcrs" us to do things certain ways for tablenames etc whats > > wrong with doing it this way? it really only effects oracle users I > > think, and they are used to doing it like this. > > You probably are 100% correct in that every known Oracle standard > would be #{table_name}_seq but there are ALWAYS edge cases and I just > think that the small amount of code required for the flexibility > would be well worth it.I have an edge case example. I have a product that I originally wrote for MySQL. A couple years ago, I ported it to Oracle for a client and continue to maintain versions for both databases. The MySQL version used a special table to store sequences (due to potential problems with MySQL''s auto-incrementation and lack of enforced foreign keys) and so I used non-standard sequence names in Oracle to match the code that was already in place. I don''t think that I''ll ever port this project to Rails, but if I do, I will need the ability to change the sequence name pattern. -- Jeremy Weathers
FYI, I submitted a patch a little bit ago that adds named sequences to the oci adapter. It uses set_sequence_name, but does not impliment a default naming scheme. That patch is here: http://dev.rubyonrails.com/ticket/1751 Perhaps the ideas could be combined? caleb On 7/21/05, Jeremy Weathers <jer-Y45+MSqgoro@public.gmane.org> wrote:> > > Personally, the seq patch is exactly how it should be done. Ive > > > been an oracle DBA for 15 years, and Have never come upon an > > > instance that sequences were not implemented that way. As far as > > > forcing the issue, granted we are using ruby, but rails semi > > > "forcrs" us to do things certain ways for tablenames etc whats > > > wrong with doing it this way? it really only effects oracle users I > > > think, and they are used to doing it like this. > > > > You probably are 100% correct in that every known Oracle standard > > would be #{table_name}_seq but there are ALWAYS edge cases and I just > > think that the small amount of code required for the flexibility > > would be well worth it. > > I have an edge case example. > > I have a product that I originally wrote for MySQL. A couple years ago, > I ported it to Oracle for a client and continue to maintain versions for > both databases. The MySQL version used a special table to store > sequences (due to potential problems with MySQL''s auto-incrementation > and lack of enforced foreign keys) and so I used non-standard sequence > names in Oracle to match the code that was already in place. > > I don''t think that I''ll ever port this project to Rails, but if I do, I > will need the ability to change the sequence name pattern. > > -- > > Jeremy Weathers > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- caleb http://www.ruejulesverne.com
Caleb Rutan wrote:> It uses set_sequence_name, but does not impliment a default naming scheme. > > That patch is here: http://dev.rubyonrails.com/ticket/1751 > > Perhaps the ideas could be combined?Yes! But we should make sure we don''t all trample on each other (you, me, and John) -- if I''d known you already had a patch, I would have added my default scheme on to yours. I''d REALLY like to get this implemented in time for 1.0, especially the default sequence name. After 1.0 I expect it''ll be harder to change the default, and it''ll help avoid nasty stares from Oracle DBAs if we get it right for the 90% case at 1.0. I suggest we go with the following approach: 1. change the default sequence name from rails_sequence to #{table_name}_seq to better handle automagically most folks using Oracle (as per my patch) 2. add the set_sequence_name method (as per Caleb''s patch) to allow folks to override. if anyone really wanted to keep the current default, they could AR::B.set_sequence_name, and have it inherited. or use the block approach to do anything else fancy (as per John''s idea) Do folks agree? If at least Caleb and John can give their consent with this approach, I''ll submit a new patch, indicating that it replaces both existing patches. Final note: would the core team prefer that I combine all 3 Oracle patches (fixing synonyms, camelCase columns, and the sequence name) into a single patch? And is it still possible to get this changed within the 1.0 release?
First, no one ever needs my consent to do something :) But yeah it seems like a very reasonable approach - the block really gives a nice option to those that would need it. -- John W Higgins wishdev-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
I agree it should all be combined into one. Sam On 7/21/05, John Higgins <wishdev-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> First, no one ever needs my consent to do something :) But yeah it > seems like a very reasonable approach - the block really gives a nice > option to those that would need it. > > -- > John W Higgins > wishdev-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
+10 On 7/21/05, John Higgins <wishdev-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> First, no one ever needs my consent to do something :) But yeah it > seems like a very reasonable approach - the block really gives a nice > option to those that would need it. > > -- > John W Higgins > wishdev-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
Sounds good to me! If you want to make your changes, then send them my way, I''ll be more than happy to put a second set of eyes on them. I''d like to get this accepted for 1.0 as well. caleb On 7/21/05, Michael Schoen <schoenm-ihVZJaRskl1bRRN4PJnoQQ@public.gmane.org> wrote:> > Caleb Rutan wrote: > > It uses set_sequence_name, but does not impliment a default naming scheme. > > > > That patch is here: http://dev.rubyonrails.com/ticket/1751 > > > > Perhaps the ideas could be combined? > > Yes! But we should make sure we don''t all trample on each other (you, > me, and John) -- if I''d known you already had a patch, I would have > added my default scheme on to yours. > > I''d REALLY like to get this implemented in time for 1.0, especially the > default sequence name. After 1.0 I expect it''ll be harder to change the > default, and it''ll help avoid nasty stares from Oracle DBAs if we get it > right for the 90% case at 1.0. > > I suggest we go with the following approach: > > 1. change the default sequence name from rails_sequence > to #{table_name}_seq to better handle automagically most > folks using Oracle (as per my patch) > > 2. add the set_sequence_name method (as per Caleb''s patch) to > allow folks to override. if anyone really wanted to keep the > current default, they could AR::B.set_sequence_name, and > have it inherited. or use the block approach to do anything > else fancy (as per John''s idea) > > Do folks agree? If at least Caleb and John can give their consent with > this approach, I''ll submit a new patch, indicating that it replaces both > existing patches. > > Final note: would the core team prefer that I combine all 3 Oracle > patches (fixing synonyms, camelCase columns, and the sequence name) into > a single patch? And is it still possible to get this changed within the > 1.0 release? > > > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- caleb http://www.ruejulesverne.com
Caleb Rutan wrote:> Sounds good to me! If you want to make your changes, then send them > my way, I''ll be more than happy to put a second set of eyes on them. > I''d like to get this accepted for 1.0 as well.Ok, I''m going to take the approach outlined, combine my 3 patches into one, and submit a single patch, probably by end of day today. Thanks for the ideas and feedback everyone!
> Ok, I''m going to take the approach outlined, combine my 3 patches into > one, and submit a single patch, probably by end of day today. Thanks for > the ideas and feedback everyone!http://dev.rubyonrails.org/ticket/1798 This patch includes my 3 previous ones, plus Caleb''s, and I''ve closed he other tickets. Please send any feedback.
Sorry about living in another timezone (and thus only seeing this thread a short time ago), but: - thanks to all for making the changes - IMHO you''ve collectively taken exactly the right approach with respect to sequence names (i.e. put in a sensible default that will work for 90%+ of cases, plus give the ability to change the default if required) I''ll try and test it out today, but as Friday = MeetingDay here, I may not get to it till next week. Regards Dave M. On 7/22/05, Michael Schoen <schoenm-ihVZJaRskl1bRRN4PJnoQQ@public.gmane.org> wrote:> > Ok, I''m going to take the approach outlined, combine my 3 patches into > > one, and submit a single patch, probably by end of day today. Thanks for > > the ideas and feedback everyone! > > http://dev.rubyonrails.org/ticket/1798 > > This patch includes my 3 previous ones, plus Caleb''s, and I''ve closed he > other tickets. > > Please send any feedback. > > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
Hmm I didnt think about this. Taken from the patch site
Fri Jul 22 06:53:48 2005: Modified by david
Won''t "change the default sequence name from rails_sequence to
#{table_name}_seq" break backwards compatibility? (We can''t really
do
that)
------------------------
It will break it, but this is how it should be in AR for oracle. If
you go into any oracle shop and tell them they need to do it with
rails sequence, you wont be using rails. The only options I see are
1. dont change (bad)
2. Implement patch as is existing apps can use set_sequence_name and
itll be fine
3. make the default sequence name changeable so you could set the
default to rails_sequence or tablename_seq ??
Thoughts? Id love to make have these patches in 1.0, what are the
options for trying to get around the compatibilty thing?
Sam
On 7/21/05, David Mitchell
<monch1962-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:> Sorry about living in another timezone (and thus only seeing this
> thread a short time ago), but:
> - thanks to all for making the changes
> - IMHO you''ve collectively taken exactly the right approach with
> respect to sequence names (i.e. put in a sensible default that will
> work for 90%+ of cases, plus give the ability to change the default if
> required)
>
> I''ll try and test it out today, but as Friday = MeetingDay here, I
may
> not get to it till next week.
>
> Regards
>
> Dave M.
>
> On 7/22/05, Michael Schoen
<schoenm-ihVZJaRskl1bRRN4PJnoQQ@public.gmane.org> wrote:
> > > Ok, I''m going to take the approach outlined, combine my
3 patches into
> > > one, and submit a single patch, probably by end of day today.
Thanks for
> > > the ideas and feedback everyone!
> >
> > http://dev.rubyonrails.org/ticket/1798
> >
> > This patch includes my 3 previous ones, plus Caleb''s, and
I''ve closed he
> > other tickets.
> >
> > Please send any feedback.
> >
> >
> > _______________________________________________
> > Rails mailing list
> > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> > http://lists.rubyonrails.org/mailman/listinfo/rails
> >
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>
Sam Mayes wrote:
> Hmm I didnt think about this. Taken from the patch site
>
> Fri Jul 22 06:53:48 2005: Modified by david
>
> Won''t "change the default sequence name from
rails_sequence to
> #{table_name}_seq" break backwards compatibility? (We
can''t really do
> that)
> ------------------------
>
> Thoughts? Id love to make have these patches in 1.0, what are the
> options for trying to get around the compatibilty thing?
>
I did think about the compatibility issue -- which is why I wanted to
get this fix made BEFORE 1.0, after which I think compatibility becomes
even more important.
I added my comments to the patch:
Clearly I agree with Caleb and Sam (since I submitted the patch). We''re
on the Rails train regardless, but I''d like to see Rails fit better
into
a typical Oracle environment as of the 1.0 release.
The upgrade path to retain compatibility is also really easy. Either:
a. I expect most folks using Oracle ALREADY have sequences named
#{table_name}_seq, so they''ll just breathe a sigh of relief and drop
the
rails_sequences they had previously been forced to use.
b. If they prefer the rails_sequence, all they need to do is add, to the
end of environment.rb:
ActiveRecord?::Base.set_sequence_name = "rails_sequence"
Is absolute compatibility with previous releases without any changes
(even the single line in option b above) by the developer is a
requirement? I didn''t think it was until POST 1.0, which is why
I''m
hoping to get this patch accepted prior to that milestone.
I would definately think this should be acceptable. But I dont make the rules ;) Sam On 7/22/05, Michael Schoen <schoenm-ihVZJaRskl1bRRN4PJnoQQ@public.gmane.org> wrote:> Sam Mayes wrote: > > Hmm I didnt think about this. Taken from the patch site > > > > Fri Jul 22 06:53:48 2005: Modified by david > > > > Won''t "change the default sequence name from rails_sequence to > > #{table_name}_seq" break backwards compatibility? (We can''t really do > > that) > > ------------------------ > > > > Thoughts? Id love to make have these patches in 1.0, what are the > > options for trying to get around the compatibilty thing? > > > > I did think about the compatibility issue -- which is why I wanted to > get this fix made BEFORE 1.0, after which I think compatibility becomes > even more important. > > I added my comments to the patch: > > Clearly I agree with Caleb and Sam (since I submitted the patch). We''re > on the Rails train regardless, but I''d like to see Rails fit better into > a typical Oracle environment as of the 1.0 release. > > The upgrade path to retain compatibility is also really easy. Either: > > a. I expect most folks using Oracle ALREADY have sequences named > #{table_name}_seq, so they''ll just breathe a sigh of relief and drop the > rails_sequences they had previously been forced to use. > > b. If they prefer the rails_sequence, all they need to do is add, to the > end of environment.rb: > > ActiveRecord?::Base.set_sequence_name = "rails_sequence" > > Is absolute compatibility with previous releases without any changes > (even the single line in option b above) by the developer is a > requirement? I didn''t think it was until POST 1.0, which is why I''m > hoping to get this patch accepted prior to that milestone. > > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
> Is absolute compatibility with previous releases without any changes > (even the single line in option b above) by the developer is a > requirement?Yes. Unless there is an extremely compelling reason, we don''t want to break people''s applications. I''m sorry, but I don''t think ''DBA wants a different sequence name'' qualifies. If you put in a configurable option, which defaults correctly then everyone is happy. Seems to me that that''s the best approach on all fronts.> I didn''t think it was until POST 1.0, which is why I''m > hoping to get this patch accepted prior to that milestone.All going well, the next release will be called 1.0beta1. We''re almost there already. -- Cheers Koz
> Yes. Unless there is an extremely compelling reason, we don''t want to > break people''s applications. I''m sorry, but I don''t think ''DBA wants > a different sequence name'' qualifies. If you put in a configurable > option, which defaults correctly then everyone is happy.I think that''s where we are -- the patch provides a configurable option which defaults correctly. DHH posted to the patch, I think he''s on board: Fri Jul 22 19:03:15 2005: Modified by david That''s the kind of feedback I was hoping for :). Okay, I''ll trust your judgement here and send anyone screaming your way. Thanks for spending the time to make Rails great on Oracle.> All going well, the next release will be called 1.0beta1. We''re > almost there already.Did I misunderstand David? Will the patch be accepted for that next release?
On 7/23/05, Michael Schoen <schoenm-ihVZJaRskl1bRRN4PJnoQQ@public.gmane.org> wrote:> > Yes. Unless there is an extremely compelling reason, we don''t want to > > break people''s applications. I''m sorry, but I don''t think ''DBA wants > > a different sequence name'' qualifies. If you put in a configurable > > option, which defaults correctly then everyone is happy. > > I think that''s where we are -- the patch provides a configurable option > which defaults correctly. DHH posted to the patch, I think he''s on board:Looks that way, the patch hasn''t been applied yet, but hasn''t been ''needied'' either ;)> > All going well, the next release will be called 1.0beta1. We''re > > almost there already. > > Did I misunderstand David? Will the patch be accepted for that next release?looks like you''ve snuck in ;) -- Cheers Koz
Cool. While I agree that breaking compatibility willy-nilly isn''t a great plan, the existing ''default'' was/is literally insane. Imagine having 10 tables, only one of which is allowed to have the number ''5'' as a primary key at any given moment. You might as well use crayon colors as your PK and throw an exception when you run out of names. Also, I''d be very surprised if there were more than 10 productionalized Rails apps on Oracle right now. The adapter only showed up along with 0.10, right? --Wilson. Michael Koziarski wrote:> On 7/23/05, Michael Schoen <schoenm-ihVZJaRskl1bRRN4PJnoQQ@public.gmane.org> wrote: > >>>Yes. Unless there is an extremely compelling reason, we don''t want to >>>break people''s applications. I''m sorry, but I don''t think ''DBA wants >>>a different sequence name'' qualifies. If you put in a configurable >>>option, which defaults correctly then everyone is happy. >> >>I think that''s where we are -- the patch provides a configurable option >>which defaults correctly. DHH posted to the patch, I think he''s on board: > > > Looks that way, the patch hasn''t been applied yet, but hasn''t been > ''needied'' either ;) > > > >>>All going well, the next release will be called 1.0beta1. We''re >>>almost there already. >> >>Did I misunderstand David? Will the patch be accepted for that next release? > > > looks like you''ve snuck in ;) >
its in for 1.0 great job guys. this will finally let me push this at work. oci is now functional! Sam On 7/23/05, Wilson <defiler-ifvz4xmYPRU@public.gmane.org> wrote:> Cool. > While I agree that breaking compatibility willy-nilly isn''t a great > plan, the existing ''default'' was/is literally insane. Imagine having 10 > tables, only one of which is allowed to have the number ''5'' as a primary > key at any given moment. > You might as well use crayon colors as your PK and throw an exception > when you run out of names. > > Also, I''d be very surprised if there were more than 10 productionalized > Rails apps on Oracle right now. The adapter only showed up along with > 0.10, right? > > --Wilson. > > Michael Koziarski wrote: > > On 7/23/05, Michael Schoen <schoenm-ihVZJaRskl1bRRN4PJnoQQ@public.gmane.org> wrote: > > > >>>Yes. Unless there is an extremely compelling reason, we don''t want to > >>>break people''s applications. I''m sorry, but I don''t think ''DBA wants > >>>a different sequence name'' qualifies. If you put in a configurable > >>>option, which defaults correctly then everyone is happy. > >> > >>I think that''s where we are -- the patch provides a configurable option > >>which defaults correctly. DHH posted to the patch, I think he''s on board: > > > > > > Looks that way, the patch hasn''t been applied yet, but hasn''t been > > ''needied'' either ;) > > > > > > > >>>All going well, the next release will be called 1.0beta1. We''re > >>>almost there already. > >> > >>Did I misunderstand David? Will the patch be accepted for that next release? > > > > > > looks like you''ve snuck in ;) > > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >