slug uniqueness as db constraint

[Elrond]

slugs need to be unique (either global or per user, I don't know).

This should not be handled in the app layer. This should be handled
at the db layer via constraints.

See `#320 </issues/320>`_ for a related issue.

current app layer check is in
models.py:MediaEntry.generate\_slug()

[Christopher Allan Webber]

`http://namlook.github.com/mongokit/indexes.html <http://namlook.github.com/mongokit/indexes.html>`_

`http://www.mongodb.org/display/DOCS/Indexes#Indexes-UniqueIndexes <http://www.mongodb.org/display/DOCS/Indexes#Indexes-UniqueIndexes>`_

[Christopher Allan Webber]

I took a look at the code and it looks like, though we might need
to add migrations to remove indexes, to add new indexes all we need
to do is simply define them in indexes = [].

...I think :)

[Christopher Allan Webber]

I think this means that if for some reason we **do** fail to detect
slug uniqueness and save and then get an error, we should try
making up for it later, maybe? We could be pretty lazy: try
catching the exception later on and try "fixing" it by re-running
the slug generation method and saving, and if that doesn't fix it,
then damn.

That's not high priority to me though. Just getting this index into
here is high priority still.

[Christopher Allan Webber]

I made a change for this, committed it, realized we actually want
uniqueness by uploader & slug (since the username is part of the
slug) then realized that we still need to fix
`http://bugs.foocorp.net/issues/340 <http://bugs.foocorp.net/issues/340>`_
...

We should fix that, then uncomment the index code, make sure it
works, push.

[Christopher Allan Webber]

Note that I created a new ticket about indexing:
`http://bugs.foocorp.net/issues/342 <http://bugs.foocorp.net/issues/342>`_

but that ticket should **not** block this ticket getting resolved.
It's okay to use mongokit's indexing solution for now.

[Christopher Allan Webber]

Interesting side effect of this I didn't realize:

`http://www.mongodb.org/display/DOCS/Indexes#Indexes-MissingKeys <http://www.mongodb.org/display/DOCS/Indexes#Indexes-MissingKeys>`_
means that if we do this slugs will not be optional but mandatory,
because you can't have one user with two MediaEntries with null
slug values. This might create a paradox:

::

    - you want to create a new mediaentry and use its objectid as the slug, but you have to save to get the objectid  
     - if you save you'll have a null slug and that breaks things

I think there's a solution though: insert the '\_id' parameter with
an ObjectId that we generate from the start:
`http://api.mongodb.org/python/current/api/bson/objectid.html?highlight=objectid#bson.objectid <http://api.mongodb.org/python/current/api/bson/objectid.html?highlight=objectid#bson.objectid>`_

that way we also don't have to do this in
mediagoblin.submit.views.submit\_start():

::

                entry.save(validate=False)

tl;dr:


-  we should generate an objectid from the beginning and set it to
   a brand new MediaEntry['\_id']
-  we should make slugs mandatory; worst come to worst they're just
   the unicode reprsentation of the MediaEntry['\_id']
-  at that point I think we can turn on the "uniqueness" index and
   we'll be safe.

[Christopher Allan Webber]

Done! And pushed.

[Elrond]

Also looks like this one went into 0.0.2

[Will Kahn-Greene]

The original url for this bug was ​http://bugs.foocorp.net/issues/337 .