table invalidation condition enhanced

[JanoValaska]

Description

During our recent efforts to increase speed of our system we noticed that in some situations django-cachalot performs unnecessary table invalidations after SELECT SQL statements.

Problematic situation

Many models in our system have DateTimeFields which track when model instance was created and updated. We name these fields "created_at" and "updated_at". When retrieving objects from the database, Django's ORM performs SELECT SQL statement behind the scenes - e.g. for our models with "created_at" and "updated_at" DateTimeFields the statement will look like this:

'SELECT some_field_name, some_other_field_name, created_at, updated_at from some_table_name;'

This SELECT SQL statement should not invalidate "some_table_name" table, because SELECT SQL statement does not change data in "some_table_name" table, but combination of "in" operator in this block of code and our field names "created_at" and "updated" trigger unnecessary "some_table_name" table invalidation.

'create' in 'SELECT some_field_name, some_other_field_name, created_at, updated_at from some_table_name;' # is True
'update' in 'SELECT some_field_name, some_other_field_name, created_at, updated_at from some_table_name;' # is True

Proposed solution

To get rid of this issue I propose to use "startswith" string method instead of "in" operator. The problematic block of code would look like this after the fix:

                    if sql.startswith('update') or sql.startswith('insert') or sql.startswith('delete') \
                            or sql.startswith('alter') or sql.startswith('create') \
                            or sql.startswith('drop'):

Rationale

These unnecessary table invalidations make table with field name that contains any of these SQL keywords('update', 'insert', 'delete', 'alter', 'create', 'drop') effectively uncacheable, because table is invalidated by all types of SQL statements.

[BertrandBordage]

One could argue that this is missing a is not None, but what you wrote is logically equivalent and marginally faster.

[coveralls]

Pull Request Test Coverage Report for Build 1893193419

• 3 of 3 (100.0%) changed or added relevant lines in 1 file are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+0.008%) to 97.198%

---

Totals
Change from base Build 1700021054:	0.008%
Covered Lines:	659
Relevant Lines:	678

---

💛 - Coveralls

[Andrew-Chen-Wang]

Thank you for the PR @JanoValaska ! And thank you for catching this @BertrandBordage