So all models are ready when connecting to the db and so
our "db" object has all models listed on it, create a
function to load all models from the media_types, etc. Call
it in setup_database()
Problem: This gives celery warnings, because celery is
imported before being setup properly. No idea how to fix
this now. So media-type loading is excluded from
load_models for now.
Kind of useful to see but... I don't think they're needed, and I'm not
super comfortable with print statements being in migrations. Seems
semi bloated!
Searching media by slug is easy on mongo. But doing the
joins in sqlalchemy is not as nice. So created a function
for doing it.
Well, and create the same function for mongo, so that it
also works.
Using the new check_media_slug_used it is possible to have
one generic generate_slug in the mixin class instead of in
each db class.
In the sql variant self.id is not always set: If the slug
alone would create a dupe the current code decides for "no
slug at all".
In two cases (generating a new slug and editing the slug)
it is nice to know in advance (before the db gets angry)
that the slug is used/free. So created a db utility
function to check for this on mongo and sql:
check_media_slug_used()
In some cases (notably the mark_entry_failed function) it
is useful to have atomic update functionality on the db. On
mongo this requires special syntax.
So created an atomic_update function for mongo and started
to use it in mark_entry_failed.
Change the media_data for video from
entry.media_data["video"] to use entry.media_data directly.
Also start a bare MediaEntry.media_data_init(**kwargs)
method for setting up the media_data and possibly
initialising it with kwargs.
To allow easier migration to the SQLAlchemy style .id give
the User and MediaEntry mongo classes an alias attribute of
.id that maps to ['_id'].
Use it in the upload process, because this was one of the
last positions with a ['_id'] instead of ._id (due to a bug
in mongokit).
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.
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.
Inside the mongo db backend, use the mongo
MigrationManager. This is hopefully the last reference to
the generic MigrationManager reference on db.util.
When initializing the database connection the current mongo
based setup checked for new migrations and warned about
them. This was mongo specific so factor'd it out into a
more generic check_db_migrations_current function in the
mongo backend.
Also created a dummy one in the sql backend.
sqlalchemy gives autoloading (hopefully caching) link to
other objects as properties. So turn get_uploader on the
current mongo based stuff into a property to ease
transition.
Instead of creating the email verication key on the db
model as a default for the field, create it in the
registration view.
Now all verification key generation is only in
auth/views.py!
1) MediaComment's author method conflicts with the author
field. So rename it to get_author.
2) Turn it from a normal function into a python property.
That means you call it by ".get_author" not by
".get_author()". This is exactly what sqlalchemy gives
us free of charge.
Starting to move the mongo specific stuff into db/mongo.
And create thin "from db.mongo.Y import z" wrappers in
db/Y.py.
Why?
1) Will make it lots easier to switch to sql for
testing/developing.
2) The mongo stuff needs to stay around after moving to
sql, because the converter needs it.
