Fork me on GitHub
Subscribe 2

Ticket #388 (fixed bug)

TruncateTable query should also reset the auto increment value

  • Created: 2011-04-07 14:27:01
  • Reported by: Reines
  • Assigned to: Franz
  • Milestone: 2.0-alpha1
  • Component: database
  • Priority: normal

When truncating a table we should also reset any auto increment values.


Franz 2011-05-14 14:50:47

  • Owner set to Franz.

Franz 2011-05-14 15:34:02

Commit 936169b to database master

#388: Reset auto_increment value when truncating table in SQLite.

Franz 2011-05-14 15:35:30

Fixed this for SQLite, hopefully, in 936169b.

This is currently untested. I would be glad if somebody could test it for me.

Franz 2011-05-14 18:21:01

Commit 274d897 to database master

#388: Reset auto_increment value when truncating table in PostgreSQL.
Note that this change was introduced in PostgreSQL 8.4, which was released in September 2009. I would actually claim that with the small share of FluxBB users that use PostgreSQL for their database, this should not be a problem.

Franz 2011-05-14 18:42:38

And another commit for PostgreSQL: 274d897.

This only works with pgSQL 8.4 upwards, though.

While I think that is ok, I would like to wait for a "go" and some testing from other people before I close the ticket.

Reines 2011-05-16 08:41:54

As I said on GitHub (copying here just for completeness):

The problem with this approach is the method is meant to return the SQL for a query. By adding a query inside the logic is being messed with and becomes rather confusing - it changes from "translate this query into SQL" to "translate this query into SQL, and possibly also do something else". If for whatever reason someone was to call the method to translate the query into SQL, without the aim of running it instantly, the auto increment value would be reset but the table not truncated. I know this isn't the case with FluxBB since we only provide a query method and not a compile/translate method - however it is still bad practice to mix logic like this.

Saying that, the only alternative I can think of is making the method return two queries (as an array for example), and adding support for such things in the query method. I think this might actually be a better idea though.

Franz 2011-10-26 21:55:17

  • Status changed from open to fixed.

With the new refactorings, this is now properly implemented.