Hi Matthew, I completely understand.
I would like to give it another chance: The migration process of the new proposal should be backwards compatible, the people could ignore the "ar_internal_metadata" table or delete it (even include a deprecation warning). If I assume the effort of the implementation, could that be something to be considered? On Friday, July 8, 2016 at 3:50:38 PM UTC+2, matthewd wrote: > > > > However, people expressed some concerns related to the database > pollution this creates. > > > > I would like to share a proposal: > > Thanks, but as you noted, this was discussed and decided 6 months ago, and > has now shipped. > > > That doesn’t preclude all further discussion, of course.. but it does mean > the bar is measurably higher: we’re not going to implement two of these > mechanisms, so a proposal is now a suggestion that we deprecate and remove > the existing functionality, and force people to migrate. Clearly, that > effort and inconvenience would require a specific, compelling argument. > > > Matthew > > > -- > mat...@trebex.net <javascript:> -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at https://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/d/optout.
