On May 24, 3:11 pm, John Firebaugh <[email protected]> wrote: > This recent commit caused some spec failures for me: > > http://github.com/jeremyevans/sequel/commit/37027c91c48d3a35186f24695... > > I run all each spec in a transaction that gets rolled back afterward, on a > DBMS that supports transactions for DDL statements. Whenever I have multiple > examples that call create_table! with the same table name, examples other > than the first are failing: > > 1. The first example calls create_table!. The table is created and its > schema is cached. > 2. The first example completes and the table creation is rolled back. > 3. The next example calls create_table!, which calls drop_table. Prior > to 37027, this would have cleared the schema before trying and failing to > drop the table (which doesn't exist due to the rollback). Now it tries and > fails to drop the table, the raise is rescued by create_table!, the example > continues but tries to use the schema cached from the previous example and > fails. > > What's the best way to fix this? Add explicit calls to remove_cached_schema > where needed in my code/specs? Or should create_table > call remove_cached_schema?
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? 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.
