django-standalone 0.4 : Python Package Index
django-standalone 0.4
use the Django ORM with standalone scripts
-*- markdown -*- Simple Standalone Scripts Using the Django ORM ===================================================== This little library is all about easing the pain of using the Django ORM for simple tools that just happen to be in need of some easy to use ORM for object persistence. The best way of course is to set up a full Django project and just use a settings.py file and using the DJANGO_SETINGS_MODULE environment variable. But when you just want to do little tools that just need some sqlite3 database to store some of their data and don't want to go for a full Django project, that is where this little library comes into play. It consists of just two modules so far: standalone.conf handles all the configuration needs, setting up standalone.models carries a base class for your models that automatically tells Python that all models created actually reside in the standalone Django app, even though they are in a different file, outside the app's namespace. As a warning: this might be seen as voodoo, bad magic or just a plain stupid idea by some people. And the official way to do it might be a much better idea for you. I myself just happen to like to have the ability to easily create standalone executable scripts that don't rely on some predefined project structure. how to get it --------------- The easiest way to get django-standalone is to use easy_install or pip: sudo easy_install django-standalone or sudo pip install django-standalone Or you can clone this repository and run the included setup.py To run the included test cases, just run the following: pythons setup.py test using in your scripts: ------------------------ First create a dynamic configuration for your database connection: from standalone.conf import settings settings = settings( DATABASE_ENGINE='sqlite3', DATABASE_NAME=options.database, ) this is all you need to do to have django modules working in your script. You would have to add additional settings if you want to use more than just the ORM, for example you will have to add TEMPLATE_DIR if you want to use the template modules. You can add any django setting you want - standalone.conf will allways extend your settings, never overwrite them. Now you just define a bunch of Models, using the provided base class in your script. The needed module standalone.models reexports everything from django.models, so you only need one. from standalone import models class MyModel(models.StandaloneModel): col1 = models.CharField(max_length=1000) col2 = models.IntegerField() col3 = models.BooleanField() def __unicode__(self): return self.col1 This will create the model and will make it available directly in your script. Additionally it will make them available in the module standalone.models for access by modules you might import in your script or for access in the django shell. This patching into standalone.models only happens for models defined in scripts, though - if your models reside in proper python modules, nothing of that kind will happen, as they are easily accessible to modules or the shell in their original module. If for any reason you need to force install into standalone.models, too (for example the testing uses this to make sure the model is accessible in a standard place even though defined in a module), you can add a class variable force_install_standalone_models with a true value. If you want to access a Django shell with access to your models, you can just use the standard way to access management commands from scripts: from django.core.management import call_command call_command("shell") The same way can be used to actually create the tables, too. Put the following lines directly after your model declarations and your script will automatically set up the database tables if they don't yet exist. from django.core.management import call_command call_command("syncdb") Using with a library of models -------------------------------- You can create library modules with model definitions based on StandaloneModel, too. These won't be patched into standalone.models, though, so you have to reference them by their own modules. They can reference models in your script by using symbolic names. from standalone import models class MyOtherModel(models.StandaloneModel): col1 = models.CharField(max_length=100) col2 = models.ForeignKey("standalone.MyModel") To write a class that again references this library model, just do something like the following: from mylibrary.mymodels import MyOtherModel class AndYetAnotherModel(models.StandaloneModel): col1 = models.ForeignKey(MyOtherModel) There are situations where you need to force a model to be installed into standalone.models to make sure you can access it from other places. One such situation is setUp methods in test cases. For that purpose, you can define an option as follows: class AllwaysInstalledModel(models.StandaloneModel): force_install_standalone_models = True col1 = models.CharField(max_length=100) This model will not only reside in it's own scope but will additionally be hooked up in standalone.models as a global value. CAVEAT: even if a model is not installed into standalone.models, they will allways be regarded as models of the standalone application. Which means, their table names will all start with 'standalone_' in the database! This has to do with the fact that django only likes model definitions that are linked to some installed django application and django-standalone behaves as an umbrella application for all models defined in the context of a script. contacting the author ----------------------- Can be done at gb at rfc1437.de in case of problems. Allthough, as the license says, essentially it's a "if you break it, you have to keep the pieces" thing. Of course, I allways like to hear war stories. Just don't blame me if this little lib kills your production server, hunts down your boss and eradicates all your companies expense records.
django-standalone 0.4 : Python Package Index
django-standalone 0.4
use the Django ORM with standalone scripts
-*- markdown -*- Simple Standalone Scripts Using the Django ORM ===================================================== This little library is all about easing the pain of using the Django ORM for simple tools that just happen to be in need of some easy to use ORM for object persistence. The best way of course is to set up a full Django project and just use a settings.py file and using the DJANGO_SETINGS_MODULE environment variable. But when you just want to do little tools that just need some sqlite3 database to store some of their data and don't want to go for a full Django project, that is where this little library comes into play. It consists of just two modules so far: standalone.conf handles all the configuration needs, setting up standalone.models carries a base class for your models that automatically tells Python that all models created actually reside in the standalone Django app, even though they are in a different file, outside the app's namespace. As a warning: this might be seen as voodoo, bad magic or just a plain stupid idea by some people. And the official way to do it might be a much better idea for you. I myself just happen to like to have the ability to easily create standalone executable scripts that don't rely on some predefined project structure. how to get it --------------- The easiest way to get django-standalone is to use easy_install or pip: sudo easy_install django-standalone or sudo pip install django-standalone Or you can clone this repository and run the included setup.py To run the included test cases, just run the following: pythons setup.py test using in your scripts: ------------------------ First create a dynamic configuration for your database connection: from standalone.conf import settings settings = settings( DATABASE_ENGINE='sqlite3', DATABASE_NAME=options.database, ) this is all you need to do to have django modules working in your script. You would have to add additional settings if you want to use more than just the ORM, for example you will have to add TEMPLATE_DIR if you want to use the template modules. You can add any django setting you want - standalone.conf will allways extend your settings, never overwrite them. Now you just define a bunch of Models, using the provided base class in your script. The needed module standalone.models reexports everything from django.models, so you only need one. from standalone import models class MyModel(models.StandaloneModel): col1 = models.CharField(max_length=1000) col2 = models.IntegerField() col3 = models.BooleanField() def __unicode__(self): return self.col1 This will create the model and will make it available directly in your script. Additionally it will make them available in the module standalone.models for access by modules you might import in your script or for access in the django shell. This patching into standalone.models only happens for models defined in scripts, though - if your models reside in proper python modules, nothing of that kind will happen, as they are easily accessible to modules or the shell in their original module. If for any reason you need to force install into standalone.models, too (for example the testing uses this to make sure the model is accessible in a standard place even though defined in a module), you can add a class variable force_install_standalone_models with a true value. If you want to access a Django shell with access to your models, you can just use the standard way to access management commands from scripts: from django.core.management import call_command call_command("shell") The same way can be used to actually create the tables, too. Put the following lines directly after your model declarations and your script will automatically set up the database tables if they don't yet exist. from django.core.management import call_command call_command("syncdb") Using with a library of models -------------------------------- You can create library modules with model definitions based on StandaloneModel, too. These won't be patched into standalone.models, though, so you have to reference them by their own modules. They can reference models in your script by using symbolic names. from standalone import models class MyOtherModel(models.StandaloneModel): col1 = models.CharField(max_length=100) col2 = models.ForeignKey("standalone.MyModel") To write a class that again references this library model, just do something like the following: from mylibrary.mymodels import MyOtherModel class AndYetAnotherModel(models.StandaloneModel): col1 = models.ForeignKey(MyOtherModel) There are situations where you need to force a model to be installed into standalone.models to make sure you can access it from other places. One such situation is setUp methods in test cases. For that purpose, you can define an option as follows: class AllwaysInstalledModel(models.StandaloneModel): force_install_standalone_models = True col1 = models.CharField(max_length=100) This model will not only reside in it's own scope but will additionally be hooked up in standalone.models as a global value. CAVEAT: even if a model is not installed into standalone.models, they will allways be regarded as models of the standalone application. Which means, their table names will all start with 'standalone_' in the database! This has to do with the fact that django only likes model definitions that are linked to some installed django application and django-standalone behaves as an umbrella application for all models defined in the context of a script. contacting the author ----------------------- Can be done at gb at rfc1437.de in case of problems. Allthough, as the license says, essentially it's a "if you break it, you have to keep the pieces" thing. Of course, I allways like to hear war stories. Just don't blame me if this little lib kills your production server, hunts down your boss and eradicates all your companies expense records.