Django Initial data dumping and loading

"manage.py dumpdata" for dumping data to json file.

$./ manage.py dumpdata app.myModel1 app.myModel2 <relative_path_to_app>/fixtures/initial_data.json
   --indent 4

"manage.py loaddata" for loading data from json file.

$ ./manage.py  loaddata <relative_path_to_app>/fixtures/initial_data.json

SVN vs GIT

In the world of programming and engineering, it is necessary to keep track of changes during the application development process. This allows developers and programmers revert unwanted changes in applications under the development process. 

Version Control Systems (VCS) are stand-alone web 2.0 applications that have made the job easier by providing systemized management of multiple revisions of the same unit of information, whether it is a simple document or a digital document, such as source codes of applications or blueprints of electronic models. VCS allows developers to work collaboratively on the same application from different locations using repositories.

The two most famous types of version control systems are:
1-     Centralized version control system - subversion (SVN)
2-     Distributed or decentralized version control system - Git

In the case of centralized version control systems, there is a single central repository and all of the changes that are made to the documents are saved in that repository. There is a client server approach in the case of CVCS, where a single repository is stored on the server that clients can also sync up to.

In case of distributed or decentralized VCS, there is a peer-to-peer approach that clients can synchronize with by exchanging patches from peer to peer. Clients can make changes in the repositories and those changes will be local to them unless they synchronize with someone else. Depending on the requirements, Git also offers a centralized repository. In other terms, each peer has a bona-fide repository which is the working copy of codebase. DVCS provides independent as well as canonical repository.

SVN vs. Git
Both VCS and DVCS are highly appreciated by their users, but I have found that DVCS has some advantages over VCS. Let’s look at the concept of VCS and DVCS in detail by comparing the available systems of both types – SVN and Git.

• With Git, clients can commit changes to their localized repositories as new revisions while being offline. However, SVN does not provide this facility as user must be online in order to push to the repository from the working copy.
• SVN help is more organized and to the point while Git provides more than what is actually required. There is some time wasted since it is difficult to get a quick reference from Git’s search.
• Git’s complete copy of the data is stored locally in the client’s system so it is extremely fast when compared to SVN. With Git there is no time wasted when waiting for network response time, but with SVN it takes longer because all of the data is stored in a centralized repository.
• There is a smaller chance of data being lost in Git because data copies are stored locally in clients systems. The number of backups available is the same as the number of users on any repository. With SVN, if there is a data loss in the central repository, it will be gone forever.
• The Git repository has an efficient memory because the data’s file format is compressed, which is not the case with SVN. Also, there are always two copies of a file in the working directory of SVN. One copy is used for storing the actual work while the other copy contains the information used to aid operations (status and commit). Git has a small index file to store the info related to a particular file. When there are a lot of documents, there is a huge impact on disk space in the SVN compared with Git.
• Git DVCS is based on the concept of branching. The working directory of a developer is itself a branch. In Git, we can easily view the working directories of developers while they are modifying two or more unrelated files at the same time as different branches stemming from the same common base revision of the project. With SVN, there is almost no concept of branching
• In Git a large number of users can commit or push data to the same repository. If someone wants to push work in a Git repository, then there is no need to worry about data lost or immediate merging of others changes because commits are not sequential in Git like SVN.
• Git allows its users to have control over the merging of data in synchronized repositories. Merges are always pulled by someone and nobody can push to commit merges in someone else’s repository. The facility to merge data is also there in SVN, but it is somewhat incomplete. SVN merge records seem to miss some of the important details that Git keeps track of.
• Git keeps track of contents while SVN keeps record of files. Because Git keeps track of contents, whenever there is even a small change in content it tracks it as a separate change. Because of this, the history of a single file in Git is split.
• Git will not allow you to checkout a subdirectory. Instead, the user will have to checkout the whole repository.  In SVN, checkouts at subdirectory level are possible.

By looking at an overview of the features of Git and SVN, we can see that Git is preferable in most circumstances. Developers, researchers, engineers and other users of VCS have more inclination towards Git, so I predict that Git will be the future of revision control.

References:
“Git's Major Features over Subversion” retrieved Dec 15, 2008 from “http://git.or.cz/gitwiki/GitSvnComparsion”

Virtual Environment for Django and python with version specified.

Python2.6 is the default Python version on Ubuntu 10.04. Now you may still want to run your Django websites with Python2.5. A nice way to do this is by creating virtual environments to handle $PYTHONPATH and avoid conflicts among different versions. Such a tool already exists: Virtualenvwrapper.

First, to install Virtualenvwrapper, we will need easy_install:

$ sudo apt-get install python-setuptools
$ sudo easy_install virtualenv
$ sudo easy_install virtualenvwrapper
$ mkdir ~/.virtualenvs

We just need to add the following lines to .bashrc.

export WORKON_HOME=$HOME/.virtualenvs
source /usr/local/bin/virtualenvwrapper.sh

And run it.

$ source .bashrc

We then create a virtual environment, here named django with Python2.5. Python2.6 is the default version on Ubuntu 10.04.

To create virtual environment 
    here -p specifies the package

$ mkvirtualenv -p python2.5 django

To use virtual environment named "django"

  bracket contains the current virtual environment

$ workon django

To close virtual environment named "django"

$ (django)...:$ deactivate

We are ready to go with Python 2.5. workon sets the current virtual environment and deactivate exits from it.

We can now add some additional Python paths on our virtual environment, for example:

$ workon django
$ (django)...:$ add2virtualenv /home/user/additional_python_path
$ (django)...:$ add2virtualenv
Usage: add2virtualenv dir [dir ...]
Existing paths:
home/user/additional_python_path
$ (django)...:$

Finally here are some other useful commands:

$ mkvirtualenv django2
$ rmvirtualenv django2
$ workon django
$ (django)...:$ deactivate
$ workon
django

Now The most important thing is "How to use virtualenv in

production ???"

For that you will need to add it's path to your PYTHONPATH.

For example if your env had for path "/home/www/my_project/env/", the path to add would be:

/home/www/env/lib/python2.7/site-packages/

You can set this up in many different ways, but if your are generating your fcgi or uwsgi interface through manage.py, simply add the following at the very top of your manage.py (before the rest):

import os
my_virtualenv_path = "/home/www/my_project/env/lib/python2.7/site-packages/"
# Add it to your PYTHONPATH
os.path.append(my_virtualenv_path)

You can adopt this to whatever your setup is, just in case you could also do the following in the shell :

export PYTHONPATH:$PYTHONPATH:/home/www/my_project/env/lib/python2.7/site-packages/

You will also need to add the directory of where your settings.py file is located to the PYTHONPATH, so django will be able to discover it, just proceed in a similar manner to do so.