I'm fully aware of hash collisions. The fact that they are so rare is why
people use them to checksum files and look for changes.

However, I fixed this to use unique_together since it's more django-like
and creates a unique constraint on the database table.


Kyle Terry | www.kyleterry.com


On Tue, Apr 30, 2013 at 5:48 PM, Martin Chase <notifications@github.com>wrote:

> In django_snailtracker/helpers.py:
>
> > -    mutex_key = '%ssnailtracker.%s.lock' % (SNAILTRACKER_TMP_PATH, key)
> > -    if os.path.exists(mutex_key):
> > -        with open(mutex_key, 'r') as tmp_f:
> > -            file_data = tmp_f.read()
> > -            if file_data:
> > -                was_made = datetime.fromtimestamp(float(file_data))
> > -                if (datetime.now() - was_made).seconds < SNAILTRACKER_TIMEOUT_SECONDS:
> > -                    raise SnailtrackerMutexLockedError("'%s' is already locked" % (key,))
> > -    with open(mutex_key, 'w') as tmp_f:
> > -        tmp_f.write(unicode(time()))
> > +def mutex_lock(model_instance):
> > +    ObjectLock = models.get_model('django_snailtracker', 'ObjectLock')
> > +    table = model_instance._meta.db_table
> > +    pk = model_instance.pk
> > +    mutex_key = hashlib.md5(
> > +        '{table}{pk}'.format(table=table, pk=pk)).hexdigest()
>
> https://en.wikipedia.org/wiki/Collision_(computer_science)
>
> The uniqueness of a string does not guarantee the uniqueness of the hash.
> It's hard to force one, the accidental likelihood is low, and the failure
> behavior in this code is safe, so like I said, it isn't likely to cause
> problems. Using a hash fells forced and unnecessary, but this code is fine
> either way.
>
> —
> Reply to this email directly or view it on GitHub<https://github.com/aquameta/django-snailtracker/pull/1/files#r4031366>
> .
>