fail_metadata used to be a dict in mongo. So a json encoded
field should be okay too.
We could use a pickled field instead, which would be more
flexible.
After a bit of discussion, we decided to drop the
pre-rendered html from the database and render it on
the fly.
In another step, we will use some proper caching method to
cache this stuff.
This commit affects the MediaComment.content_html part.
After a bit of discussion, we decided to drop the
pre-rendered html from the database and render it on
the fly.
In another step, we will use some proper caching method to
cache this stuff.
This commit affects the MediaEntry.description_html part.
After a bit of discussion, we decided to drop the
pre-rendered html from the database and render it on
the fly.
In another step, we will use some proper caching method to
cache this stuff.
This commit affects the User.bio_html part.
Many thanks go to Svavar Kjarrval who has taken a deeper
look at our current sql db design and made a bunch of
suggestions. The suggestions are currently put as TODO
items in the docstrings. This way we can keep track of
them directly where we need it.
- Add default for User.email_verified
- Add default for MediaEntry.state
- Let PathTupleWithSlashes store [] as "NULL",
but not handling the reverse properly yet!
- Add _id alias field to MediaEntry and MediaComment
These changes allow all of the rest of the code to use tags
in sql as they were used on mongo. It's not efficient at
all, as changing tags usually means to remove all old tags
and adding all new.
The only problem here is: Old slugs for tags are not
removed, because they're shared across all MediaTags and
dropping orphans is not always easy.
The upcoming SQL database will allow having media without a
slug again. This might especially be useful for API
support, where the uploaded image (media) does not have
*any* information to generate a slug from.
This code change mostly allows the sql backend to have no
slug in its model and improves some parts to properly
handle that.
It specifically does not have any web frontend support to
edit/create MediaEntries with no slug.
- This adds a new SQL table field type for path tuples.
They're stored as '/' separated unicode strings.
- Uses it to implement a MediaFile table.
- Add relationship and proxy fields on MediaEntry to give a
nice media_files "view" there.
- Let the converter fill the MediaFile.
A bunch of functions on the db objects are really more like
"utility functions": They could live outside the classes
and be called "by hand" passing the appropiate reference.
They usually only use the public API of the object and
rarely use database related stuff.
Goals:
- First, simple: Share the code with the SQL objects, so
that the code doesn't need to be duplicated.
- Second, it might unclutter the db models and make them
more into "model only" stuff.
- Doesn't really hurt.
MediaEntry now has a get_uploader (property) loading the
appropiate User object for the MediaEntry (and caches it).
MediaComment has the same for author as get_author.
While creating the new SQL model, the "state" field of
MediaEntry was left out. Currently using a plain unicode
string for it.
Maybe should use sqlalchemy.types.Enum?
In trying to ease the migration to SQL, created an
interface to sqlalchemy that looks a lot like the interface
that is currently in use.
*WARNING* Work in progress
Run bin/python mediagoblin/db/sql/models.py and watch the
create tables on a memory sqlite db.
Also unicode strings need unicode defauls. Warning by
sqlalchemy.
