Login

Tag "orm"

30 snippets

Snippet List

orm_tools

This module contains classes that add new behavior to Django's ORM. Classes include: **Session** * Forces QuerySet objects to return identical instances when objects with the same primary key are queried. * Similar to [SQLAlchemy Session](http://www.sqlalchemy.org/docs/orm/session.html) **GraphSaver** * Save entire object graphs at once. * Automatically detects object dependencies and saves them in the correct order. **Collection** * Easier one-to-many relationships. Instructions and more information on [limscoder.com](http://www.limscoder.com/2011/01/django-orm-tools.html).

  • session
  • db
  • orm
Read More

Custom model field for mysql time type.

Django does not have a suitable model field can process time type in mysql, the DateTimeField built-in django can not process more than 24 hours. That's why the code born. **Simply usage** `from myapp.models import TimeAsTimeDeltaField, SECONDS_PER_MIN, SECONDS_PER_HOUR, SECONDS_PER_DAY class EstimatedTime: days = None hours = None minutes = None seconds = None class Case(models.Model): estimated_time = TimeAsTimeDeltaField(null=True, blank=True) def get_estimated_time(self): estimated_time = EstimatedTime() if self.estimated_time: total_seconds = self.estimated_time.seconds + (self.estimated_time.days * SECONDS_PER_DAY) days = total_seconds / SECONDS_PER_DAY hours = total_seconds / SECONDS_PER_HOUR - days * 24 minutes = total_seconds / SECONDS_PER_MIN - hours * 60 - days * 24 * 60 seconds = total_seconds % SECONDS_PER_MIN estimated_time.days = days estimated_time.hours = hours estimated_time.minutes = minutes estimated_time.seconds = seconds return estimated_time else: return estimated_time

  • models
  • orm
  • database
  • field
  • timedelta
Read More

Improved Pickled Object Field

[Based on snippet #513 by obeattie.](http://www.djangosnippets.org/snippets/513/) **Update 10/10/09:** [Further development is now occurring on GitHub, thanks to Shrubbery Software.](http://github.com/shrubberysoft/django-picklefield) Incredibly useful for storing just about anything in the database (provided it is Pickle-able, of course) when there isn't a 'proper' field for the job. `PickledObjectField` is database-agnostic, and should work with any database backend you can throw at it. You can pass in any Python object and it will automagically be converted behind the scenes. You never have to manually pickle or unpickle anything. Also works fine when querying; supports `exact`, `in`, and `isnull` lookups. It should be noted, however, that calling `QuerySet.values()` will only return the encoded data, not the original Python object. *Please note that this is supposed to be two files, one fields.py and one tests.py (if you don't care about the unit tests, just use fields.py).* This PickledObjectField has a few improvements over the one in [snippet #513](http://www.djangosnippets.org/snippets/513/). 1. This one solves the `DjangoUnicodeDecodeError` problem when saving an object containing non-ASCII data by base64 encoding the pickled output stream. This ensures that all stored data is ASCII, eliminating the problem. 2. `PickledObjectField` will now optionally use `zlib` to compress (and uncompress) pickled objects on the fly. This can be set per-field using the keyword argument "compress=True". For most items this is probably **not** worth the small performance penalty, but for Models with larger objects, it can be a real space saver. 3. You can also now specify the pickle protocol per-field, using the protocol keyword argument. The default of `2` should always work, unless you are trying to access the data from outside of the Django ORM. 4. Worked around a rare issue when using the `cPickle` and performing lookups of complex data types. In short, `cPickle` would sometimes output different streams for the same object depending on how it was referenced. This of course could cause lookups for complex objects to fail, even when a matching object exists. See the docstrings and tests for more information. 5. You can now use the `isnull` lookup and have it function as expected. A consequence of this is that by default, `PickledObjectField` has `null=True` set (you can of course pass `null=False` if you want to change that). If `null=False` is set (the default for fields), then you wouldn't be able to store a Python `None` value, since `None` values aren't pickled or encoded (this in turn is what makes the `isnull` lookup possible). 6. You can now pass in an object as the default argument for the field without it being converted to a unicode string first. If you pass in a callable though, the field will still call it. It will *not* try to pickle and encode it. 7. You can manually import `dbsafe_encode` and `dbsafe_decode` from fields.py if you want to encode and decode objects yourself. This is mostly useful for decoding values returned from calling `QuerySet.values()`, which are still encoded strings. The tests have been updated to match the added features, but if you find any bugs, please post them in the comments. My goal is to make this an error-proof implementation. **Note:** If you are trying to store other django models in the `PickledObjectField`, please see the comments for a discussion on the problems associated with doing that. The easy solution is to put django models into a list or tuple before assigning them to the `PickledObjectField`. **Update 9/2/09:** Fixed the `value_to_string` method so that serialization should now work as expected. Also added `deepcopy` back into `dbsafe_encode`, fixing #4 above, since `deepcopy` had somehow managed to remove itself. This means that lookups should once again work as expected in **all** situations. Also made the field `editable=False` by default (which I swear I already did once before!) since it is never a good idea to have a `PickledObjectField` be user editable.

  • model
  • db
  • orm
  • database
  • pickle
  • object
  • field
  • type
  • pickled
  • store
Read More

More readable Enumeration class for Django choices

We currently use two-level tuples to specify choices of a field in models or forms. But, because it has only (value, verbose name) pair, the readability is bad whenever we indicate a specific choice value in our Python codes. So I made a small class that does "magic" for this: A Named Enumeration. Instead of `myobj.status == 0`, use `myobj.status == STATUS.UNREVIEWED`, for example.

  • choices
  • model
  • orm
  • enumeration
  • enum
Read More

UnicodeReprMixIn

Add's updated and created fields to a model if mixed in. Example that uses the name as the representation: class Company(models.Model, UnicodeReprMixIn): """ A representation of a comic book company. """ name = models.CharField(max_length=255) slug = models.SlugField() logo = models.ImageField(upload_to=os.path.join('upload', 'company_logos')) url = models.URLField(verify_exists=True) _unicode = "name"

  • model
  • unicode
  • orm
  • mixin
  • __unicode__
Read More

Table Creation Using ORM Standalone

I love the Django templates and ORM, but I prefer to use CherryPy as my web server. So I want to be able to do the equivalent of "python manage.py sql" but without actually needing to have a Django application. So I stick all of my models in a file named "models.py" and then run this script and it prints out all of the CREATE TABLE statements for my database.

  • orm
Read More

Pickled Object Field

*Incredibly useful for storing just about anything in the database (provided it is Pickle-able, of course) when there isn't a 'proper' field for the job:* A field which can store any pickleable object in the database. It is database-agnostic, and should work with any database backend you can throw at it. Pass in any object and it will be automagically converted behind the scenes, and you never have to manually pickle or unpickle anything. Also works fine when querying. **Please note that this is supposed to be two files, one fields.py and one tests.py (if you don't care about the unit tests, just use fields.py)**

  • model
  • db
  • orm
  • database
  • pickle
  • object
  • field
  • pickled
Read More

Querying on existence of a relationship

When you have two models joined by a foreign key, it's common to want to retrieve a set of objects from the "target" of the foreign key based on whether there are any objects "pointing" to them. This snippet demonstrates how to do so, using the `extra` method of the default model manager. Note that this is probably more efficient than using two ORM methods (e.g., selecting all values from one table, and using an `id__in` lookup on the other) since it does the whole thing in one query and avoids instantiating any intermediate objects.

  • models
  • orm
  • foreign-keys
Read More

Binding pre-existing tables with dynamically created class models

This snippet proposes a solution for pre-exisiting database tables that have no counterpart in your django application models.py module. My use case was a comercial systems where pricing tables were created on-the-fly as a result of a stored procedure's execution inside the database. These pricing tables had no counterpart class model. Therefore, to access these tables from Python code you had to bypass Django's ORM and use plain-old SQL through cursos.execute(). This snippet's strategy is to create a (model) class on the fly and inject that class inside models.py namespace. After that you can use the generated class and Django's ORM machinery to access the tables, as if they were created by syncdb.

  • orm
  • dynamic-model
Read More

Ordered items in the database - alternative

Every now and then you need to have items in your database which have a specific order. As SQL does not save rows in any order, you need to take care about this for yourself. No - actually, you don't need to anymore. You can just use this file - it is designed as kind-of plug-in for the Django ORM. Usage is (due to use of meta-classes) quite simple. It is recommended to save this snippet into a separate file called `positional.py`. To use it, you only have to import `PositionalSortMixIn` from the `positional` module and inherit from it in your own, custom model (but *before* you inherit from `models.Model`, the order counts). Usage example: Add this to your `models.py` from positional import PositionalSortMixIn class MyModel(PositionalSortMixIn, models.Model): name = models.CharField(maxlength=200, unique=True) Now you need to create the database tables: `PositionalSortMixIn` will automatically add a `postition` field to your model. In your views you can use it simply with `MyModel.objects.all().order_by('position')` and you get the objects sorted by their position. Of course you can move the objects down and up, by using `move_up()`, `move_down()` etc. In case you feel you have seen this code somewhere - right, this snippet is a modified version of [snippet #245](/snippets/245/) which I made earlier. It is basically the same code but uses another approach to display the data in an ordered way. Instead of overriding the `Manager` it adds the `position` field to `Meta.ordering`. Of course, all of this is done automatically, you only need to use `YourItem.objects.all()` to get the items in an ordered way. Update: Now you can call your custom managers `object` as long as the default manager (the one that is defined first) still returns all objects. This Mix-in absolutely needs to be able to access all elements saved. In case you find any errors just write a comment, updated versions are published here from time to time as new bugs are found and fixed.

  • db
  • orm
  • database
  • plugin
  • mixin
Read More

Ordered items in the database

First off: This snippet is more or less obsoleted by [snippet #259](/snippets/259/). The way that snippet #259 uses feels cleaner and more usable. It is basically the same code but the magic works a little bit different. In case you prefer this way, I've left this snippet as-is. Maybe you know this problem: you have some objects in your database and would like to display them in some way. The problem: the Django ORM does not provide any way to sort model instances by a user-defined criterion. There was already a plug-in in SQLAlchemy called [orderinglist](http://www.sqlalchemy.org/docs/plugins.html#plugins_orderinglist), so implementing this in Django was basically not a big deal. Usage is (due to use of meta-classes) quite simple. It is recommended to save this snippet into a separate file called `positional.py`. To use it, you only have to import `PositionalSortMixIn` from the `positional` module and inherit from it in your own, custom model (but *before* you inherit from `models.Model`, the order counts).

  • db
  • orm
  • database
  • plugin
  • mixin
Read More

Filter on Multiple M2M Objects Simultaneously

This snippet should allow you to do queries not before possible using Django's ORM. It allows you to "Split" up the m2m object you are filtering on. This is best described by example: Suppose you have `Article` and `Tag`, where `Article` has a m2m relation with `Tag` (`related_name = 'tag'`). If I run: from django.db.models.query import Q Article.objects.filter(Q(tag__value = 'A') & Q(tag__value = 'B')) > # no results I would expect to get no results (there are no tags with both a value of 'A' and 'B'). However, I *would* like to somehow get a list of articles with tags meeting that criteria. Using this snippet, you can: from django.db.models.query import Q from path.to.qsplit import QSplit Article.objects.filter(QSplit(Q(tag__value = 'A')) & QSplit(Q(tag__value = 'B'))) > # articles with both tags So now they are split into different `Tag` entries. Notice how the `QSplit()` constructor takes a `Q` object---it's possible to give this any complicated Q-type expression.

  • models
  • q
  • m2m
  • db
  • orm
Read More