James Byrne wrote in post #955871: > Marnen Laibow-Koser wrote in post #955846: > >> As a former stored-procedure fan myself, I would strongly encourage you >> to move those into the application layer. Maintenance of SPs is a >> nightmare, version control and testing are generally difficult to >> impossible, and they are generally just not worth the trouble. >> > > This is not possible in a audit compliant environment.
Perhaps. I'm not at all convinced of this, and there seem to be some circumstances in which logic in the DB actually makes things harder to audit, not easier. If you can explain what audit functionality you think you need from SPs and triggers, I'll try to provide more specific advice. > And the > generation of both functions and triggers in the production and > development database is properly handled by the Rails-3 Active Record > migration task. The question at hand is: Is there a bug in the > db:test:prepare task in Rails-3 or not? I am aware that this is the question at hand, but I do not think it is the only question to be answered. Your life really will be easier if you get rid of your stored procedures and triggers. > If not then what need I do > differently? I suspect db:test:prepare is loading the DB from the schema file, not rerunning all the migrations -- at least, that's what it *should* be doing. If I am right about this, then you need to get the SPs and triggers into the schema file. There may be a plugin to do that (as Foreigner does for foreign keys); if not, then you'll have to set the schema dumper to use SQL instead of Ruby for the schema file. Best, -- Marnen Laibow-Koser http://www.marnen.org [email protected] -- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
