On May 24, 7:09 pm, John Firebaugh <[email protected]> wrote: > On Mon, May 24, 2010 at 6:58 PM, Jeremy Evans <[email protected]>wrote: > > > > > There's a few options, I'm not sure which is best: > > > 1) Have create_table remove the cached entry before doing anything. > > 2) Have drop_table remove the cached_entry before instead of after. > > It was moved to after in drop_table and other methods for consistency > > with a necessary change to alter_table when the cached schema needs to > > be removed after, not before. > > 3) Make remove_cached_schema take a block that yields and uses ensure > > to ensure the schema is dropped afterward (even if an exception is > > raised), and use the block form for the schema methods > > > 1) is probably a good idea even without considering your issue, since > > users could use Database#run "DROP TABLE ..." to drop a table, and if > > you are creating a new table, any cached schema is going to be stale. > > I'm not sure either 2) or 3) is necessary if we do 1). For your > > issue, I think 1) by itself would fix it. What do you think we should > > do? > > 1) alone sounds good to me too.
Cool. I've applied the patch at http://pastie.org/975610.txt to my private branch, I'll push it to GitHub after testing tomorrow. Thanks for catching this. Jeremy -- You received this message because you are subscribed to the Google Groups "sequel-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/sequel-talk?hl=en.
