Posting, numbering and updating docs to db

[alexandre...@gmail.com]

Hi

I'm trying to post some docs to database, and have some issues associated 
that I'm not sure howto implement in django.

class DocNumber(models.Model):
tipo=models.CharField(max_length=2)
   Year=models.IntegerField()
   Number=modelsIntegerField()

class Doc(models.Model):
   Tipo = models.CharField(max_length=2)
   Year=models.IntegerField()
   Number=modelsIntegerField()
.

class DocLine(models.Model):
doc=ForeignKey(Doc)
product=ForeignKey(Product)
price=models.FloatField()
.


In my actual native app, when I save a document I've the following procedure

1.  start a transaction
2. if is a new doc get a new number from DocNumber increment that number 
(update lock this table to ensure no more docs with this number)
3. if is an update remove the old doc from stock (old lines)
4. save Doc and DocLines to DB
5. update the stock according to new lines
6. commit the transaction


I'm not able for the moment to implement this procedure in django, it seems 
to me that it should go in Doc save method, but  not sure how to get the 
number in a unique maner and update stocks accordingly?

Anyone has been trough the same problem, as this is a common pattern for me.

Kind Regards
Alexandre Rua





-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Django in the Mac App Store with BitNami

[victoria]

Hi,

On Sat, May 18, 2013 at 7:13 PM, Artem Zinoviev  wrote:
>
> sorry, but why you use apache?

We include Apache and mod_wsgi because it is what most of users use in
production. Of course you can use the django development server.
However when an user tries to configure his application with Apache it
is not always straight forward. Including Apache makes you easier to
test this configuration. Basically we allow you to use the default
server but we also make easier to test your applications with Apache.

one-click deployment in local computer? or
> in heroku?

Local computer. This distribution is mainly intended for development
in your machine. In BitNami we also offer virtual machines and cloud
images with a very similar environment so migrate your apps to
production should be easier. Of course you don't need to use BitNami
for production, you can just use the native installer for development
and then use any other environment for hosting your application.

> Can i use createproject from template?

Yes, you should be able to use it.

>why You don`t like old way
> by - mkvirtualenv spam && pip install django && django-admin.py startproject

Unfortunately applications in the Mac Store are running under a
sandbox which introduce several restrictions one of them is that it is
not compatible with virtualenv. This distribution in the Mac App Store
is mainly intended for getting started with Django (due to the sandbox
restrictions), the users can quickly have a Django environment, open
the official Django documentation and start playing with it. We also
offer native installers for Windows, Linux and Mac OS X (out from the
Mac App Store) which don't have these limitations.

> ?? Django is not CMS... :-)

Of course not. Sorry, do we mention that somewhere in our
documentation? I'd like to fix it.


Thanks for taking the time to take a look at it. I really appreciate
it. Please don't hesitate to let me know any other question or comment
that you may have. Best regards,

Victoria.


>
> четверг, 16 мая 2013 г., 12:46:02 UTC+3 пользователь victoria написал:
>>
>> Hi,
>>
>> I guess that most of you already have a Django development environment set
>> up. However I want to share this with the django users. In BitNami we have
>> been packaging Django for a while together with Python, Apache and
>> MySQL/PostgreSQL and providing one-click deployment options. Now we have
>> prepared a package for the Mac App Store which makes it even easier to get
>> started for Mac OS X users. You need to download BitNami Stack for Django
>> from the Mac App Store and follow the official Django guides. The
>> installation steps can be skipped because BitNami does it for you. I hope
>> you enjoy Django even more with this new deploy option. We wrote a blog post
>> entry about it in case this sounds interesting to you and you want to learn
>> more about this.
>>
>> If you try it please feel free to let me know your comments I would really
>> appreciate to have your feedback.
>>
>> Thanks,
>>
>> Victoria.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Custom RadioSelect() Label from Model Data

[Christian Schmitt]

Hello, is there a way to get a Custom Label for a RadioSelect() widget?

I have a Model and wanted to get a label like:

'
 
{{ customer.name }}
{{ customer.address.city }}
{{ customer.address.zip }}
'

Is there a way to get certain output?
I heard about the RadioSelect Renderer but i can only access the 
__unicode__ output i definied for the model. Is there a better / other way 
to implement such functionallity?

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Bulk] Re: Template Inheritance doubt

[Parin Porecha]

Yes, this approach is also good. Besides, I have no problem in letting the
html tags remain in header and footer.
Thanks :)


On Tue, May 21, 2013 at 3:58 AM, Sam Solomon  wrote:

> If you are mainly using this for splitting stuff into multiple files, here
> is what we do to accomplish the same thing but keep it so that templates
> always inherit base.html instead of sidebar.html:
>
> base.html:
> {% extends 'header.html' %}
>
> {% block main %}
> 
> {% endblock main %}
>
> header.html:
> {% extends base_footer_template|default:"includes/footer.html" %}
>
> {% block base_everything %}
> 
>  overridable blocks for navigation etc>
> {% block main %}{% endblock main %}
> {% endblock base_everything %}
>
> footer.html:
> {% block base_everything %}{% endblock %}
> 
> 
>
>
> So it's a little weird that the html tags are in header.html and
> footer.html but it does allow the code to be logically separated otherwise.
>
> Also, because of the |default filter, you can render header.html without
> the footer if you need to (we did this for a while when we were playing
> around with "sharing" the overall layout with a wordpress install. (We'd
> have the django server render the header and footer separately and the
> wordpress server would cache the result and use the header and footer in
> it's main template (would only show the logged out versions of the
> header/footer).)
>
> On Monday, May 20, 2013 1:52:15 AM UTC-7, Parin Porecha wrote:
>
>> Dow,
>> I am using the chained approach which you suggested ( base -> topbar ->
>> sidebar -> view1 ). It works perfectly as i wanted :)
>>
>> Thanks!
>>
>>
>> On Sun, May 19, 2013 at 10:50 PM, Dow Street  wrote:
>>
>>>  Hi.  I'm not sure, but we may be using the terms 'parent' and 'child'
>>> differently (i.e. what you're calling a child I'm calling a parent?).  I
>>> have only used django template inheritance where a given template file has
>>> at most one {% extends %} tag in it - that is what I am referring to when I
>>> say 'has at most one parent'.  However, the base.html template (the parent)
>>> is extended by many different child templates (e.g. view1.html).  Is this
>>> what you are thinking as well?
>>>
>>> If you want a template to inherit from multiple parents - e.g. include
>>> multiple {% extends %} tags - well, that is not something I have done
>>> previously (and I can't say whether that model is supported).  However, you
>>> can achieve comparable functionality (I think) by adding a layer in the
>>> inheritance hierarchy - for example:
>>>
>>> base.html - has empty blocks for topbar and sidebar
>>> topbar.html - extends base.html and contains the code for the topbar
>>> sidebar.html - extends topbar.html and contains the code for the sidebar
>>> view1.html - extends sidebar.html and contains the code specific to that
>>> page
>>>
>>> If you load the view1.html template in your view function all those {%
>>> extends %} tags will cause the django template engine to walk the
>>> hierarchy, starting from base -> topbar -> sidebar -> view1, leaving you
>>> with a single 'merged' html file.  At each step, if a child template has a
>>> block with the same name as one of the parents, the child block will
>>> overwrite the contents of the parent block.  Does this make sense?
>>>
>>> (and I should note that I am by no means an expert in the django
>>> template processor - this is just my understanding).
>>>
>>> R,
>>> Dow
>>>
>>>
>>> On May 18, 2013, at 11:12 PM, Parin Porecha  wrote:
>>>
>>> > Dow,
>>> > I am trying to have multiple children of the same parent. And thats
>>> why I'm not able to decide which child to load. Anyways, the sidebar and
>>> topbar are more or less static, so I guess there isn't much need to have
>>> separate files for them. I want to have them different so that developing
>>> that section of the website would be easier. In the end, I want to merge
>>> all those different sections into one file and load that in my view. Can
>>> you please help me with this ?
>>> >
>>> > Artem,
>>> > Yes, I get it :) Thanks!
>>> >
>>> >
>>> > On Sat, May 18, 2013 at 9:56 PM, Artem Zinoviev 
>>> wrote:
>>> > if you have base.html and sidebar.html, base.html file just declare {%
>>> block sidebar %} section and sidebar.html make implementation of it, if you
>>> have SidebarView, then you load sidebar.html and this file take all from {%
>>> extends base.html %}. And if you try load base.html from SidebarView - you
>>> get it :-), but {% block sidebar %} section be blank...
>>> >
>>> > суббота, 18 мая 2013 г., 12:14:37 UTC+3 пользователь Parin Porecha
>>> написал:
>>> > Hi,
>>> >
>>> > I have just started to learn Django's template inheritance and I am
>>> stuck due to this problem -
>>> > In my application's 'base.html', I have defined two blocks -
>>> > {% block topbar %}{% endblock topbar %}
>>> > and
>>> > {% block sidebar %}{% endblock sidebar %}
>>> >
>>> > I have 2 templates - 'sidebar.html' which extends {% block sidebar %}
>>> > and 't

Data Access Across Subdomains?

[support]

Hello,

I am fairly new to both django, so please excuse this question if there is 
a doc I missed somewhere that answers it...  Anyhow, I'm planning on moving 
a large drupal site into django.  Currently the site - yinyanghouse.com - 
has more or less static content, dynamic community submitted content and 
some ecommerce functionality.  I'm considering moving the site into three 
domains to ease some aspects of administration and also give us the future 
possibilities of moving some parts into other systems - like the static 
parts into a static site generator and the store into a 3rd party system - 
for example.

So we would have www.yinyanghouse.com, store.yinyanghouse.com, 
community.yinyanghouse.com .

Now my question is that we currently have data queries that are important 
to the site that would then encompass the three subdomains.  I've read a 
little on the django "sites" framework, but it wasn't clear if you could 
perhaps share a category between all 3 subdomains, for example, and allow 
you to display data from one site on another site.  For example, we 
currently have a "conditions" meta-page say "low back pain" and this pulls 
in information from all over including related products from our store, 
related acupuncture points from our static collection of information, etc.  
So in that case community.yinyanghouse.com/conditions/low-back-pain would 
pull in products from store.yinyanghouse.com tagged with "low back pain" in 
the conditions category as well as acupuncture points from 
www.yinyanghouse.com tagged with "low back pain".

Is this possible?  Is it too much work for the benefits we would get in 
clearer layouts between sites, probably better caching prospects, etc.?

Thanks for any ideas/feedback you can offer!
-Chad.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Understanding Django transactions

[Michael]

 

I've been reading up on how transactions work in Django 1.5 and how they 
will work in 1.6. I think I have a grasp of things, but I wanted to reach 
out on here to just check that my understanding of things is correct, and 
ask a question or two.

*Django 1.5:*

   - The database-level auto-commit is turned OFF. 
   - SQL standards dictate that every query opens a transaction if one does 
   not already exist. This happens regardless of the database's auto-commit 
   setting. 
   - After each Django ORM operation (read or write), Django commits this 
   open transaction. This emulates the database-level auto-commit. 
   - Transaction decorators cannot be nested. When one is opened, any 
   previous transaction will be committed. 
   - When executing raw SQL (with a database cursor), Django marks the 
   current transaction as dirty but does not issue a commit. If data changes 
   were made then they need manually committing. *Why do the 
**docs*
   * say that you only need to commit the change if data was changed? If 
   the transaction is marked as dirty regardless of a read or a write, would 
   it not always need committing or rolling back to ensure the transaction is 
   properly closed by the end of the connection?* 
   - Setting TRANSACTIONS_MANAGED to True stops Django from sending any 
   commits after ORM operations. The database-level auto-commit is still 
   disabled.* With this setting, using any Django ORM read or write 
   operation (all wrapped in `transaction.commit_on_success`) fails 
   with TransactionManagementError('This code isn't under transaction 
   management'). Is this expected?* 

*Django 1.6:*

   - The database-level auto-commit is turned ON. 
   - Every database operation via the ORM will be committed using the 
   database's auto-commit, including any custom SQL executed with the database 
   cursor. 
   - The `atomic` decorator / context manager either starts a new 
   transaction, or creates a new savepoint if it's nested within an existing 
   transaction. They are committed as long as no exception is raised. 
   - If ATOMIC_REQUESTS is specified in the database config, all views are 
   wrapped in `atomic`, unless it's wrapped in `non_atomic_requests`. 
   - If you set AUTOCOMMIT to False in a database configuration, this will 
   disable the database-level auto-commit. All DB reads and writes will need 
   manually wrapping in transactions. *The 
**docs*
   * say that with this disabled, Django won't perform any commits. Does 
   this mean that the `atomic` decorator won't work properly and you have to 
   use the underlying database library to handle transactions? In 1.6 it would 
   appear that Django never performs a commit outside of `atomic`, so I'm 
   confused by this comment!* 

I'd really appreciate any information if some of what I understand to be 
true is not accurate.

Many thanks!

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Deploying CSS/JS with pip

[Thomas Güttler]

Hi,

I like one part of fanstatic[1]:

You can create dependencies to JS modules. The JS files are available on pypi 
and this
way installing them is very easy.

example: You can have a requirement on "js.jquery_datatables" in you
requirements.txt file: https://pypi.python.org/pypi/js.jquery_datatables

This makes automated deployment very easy.

There is a django integration, but it looks dead. There was no development
during the last months.

There are some parts of fanstatic which are not need if you use django, but
the js/css packages could be useful for us.

Does anybody use fanstatic together with django?

My goal is to easy the automated deployment.

How do you handle the dependency on external resources like jquery libraries? 
Do you store
a tgz file inside your source code repository?

Regards,
  Thomas Güttler




[1] http://www.fanstatic.org/en/latest/

--
You received this message because you are subscribed to the Google Groups "Django 
users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: new to Django and building web applications. Advice with postgresql

[Tom Evans]

On Sun, May 19, 2013 at 11:51 PM, Scott Anderson
 wrote:
> On Sunday, May 19, 2013 11:18:07 AM UTC-4, WongoBongo wrote:
>>
>> You don't have to become an expert with postgres to use Django. You can do
>> most of the db development using SQLite and hold off on postgres until you
>> are ready to deploy.
>
>
>
> I highly recommend *against* waiting for PostgreSQL until deployment. There
> are significant differences between SQLite, PostgreSQL, and MySQL. If you
> wait until deployment to test on your production database you will find
> yourself fixing and changing things at the last minute. Start testing on
> your production deployment database as soon as possible.

The purpose of using an ORM is to make your application database
agnostic. You should not find that changing DB engine is overly
taxing.

>
> Even if you are using an ORM there are enough differences between the
> databases (and/or their drivers!) that you can run into issues. Four
> examples of MySQL vs. SQLite, but the same recommendation holds true for
> PostgreSQL as well:
>
> 1) MySQL truncates DateTimeFields to the second; SQLite stores the
> milliseconds.
>
> 2) SQLite can re-use keys if a row is deleted; MySQL will not. This can
> affect unit tests.
>
> 3) Each database may use a different natural order when no ORDER BY is used.
>
> 4) SQLite allows 0 as a PK, MySQL does not.
>
> Also, you'll benefit from the exercise of setting up and using the same
> database you'll see in production.
>

Not all of these statements are wholly accurate, mysql will re-use
keys when necessary (but doesn't try to 'back fill' the set of used
ids), and mysql is also perfectly happy with 0 as a primary key, but
will replace it with the next auto increment id if the field is an
auto increment field. There is no 'natural ordering' of un-ordered
results, the order is undefined, and undefined behaviour is undefined.

The point is, installing and learning the ins and outs of an RDBMS is
not necessary to using Django. If you think you are stuck trying to
install or understand postgres, just ignore it and use sqlite. You can
always change at a later date.

Cheers

Tom

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Django Celery w/ Amazon RDS and Memcached

[Joey Espinosa]

Hey guys, I'm having an issue with running Celery on an EC2 instance, using
the database transport (django://) and memcached as the cache backend.

I have Celery running via Supervisor, and I can tail the log and see that
it's successfully getting a specific task (for reloading the database).
However, it never completes, and it just hangs. This exact scenario works
perfectly on my own local machine running the same OS, same build of the
code, and MySQL 5.5 instead of RDS.

Has anyone else run into similar issues? Note: I can't switch to PostgreSQL
(though I'd love to), so I don't have many options in the way of databases.
I can always pitch a solution though. Thanks in advance.
--
Joey "JoeLinux" Espinosa*
*



-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Django Celery w/ Amazon RDS and Memcached

[Joey Espinosa]

Nevermind, everyone. Turned out to be simply my fault (had a shell
connection to the database open). *facepalm*

--
Joey "JoeLinux" Espinosa*
*




On Tue, May 21, 2013 at 8:29 AM, Joey Espinosa wrote:

> Hey guys, I'm having an issue with running Celery on an EC2 instance,
> using the database transport (django://) and memcached as the cache backend.
>
> I have Celery running via Supervisor, and I can tail the log and see that
> it's successfully getting a specific task (for reloading the database).
> However, it never completes, and it just hangs. This exact scenario works
> perfectly on my own local machine running the same OS, same build of the
> code, and MySQL 5.5 instead of RDS.
>
> Has anyone else run into similar issues? Note: I can't switch to
> PostgreSQL (though I'd love to), so I don't have many options in the way of
> databases. I can always pitch a solution though. Thanks in advance.
> --
> Joey "JoeLinux" Espinosa*
> *
>  
> 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

access request variable from middlewares into my main project urls

[Nikhil Verma]

Hello Guys


I want to make the urls dynamic and change according to roles in the
project for every app.
Example if there is role x so it should change like x/manage/view_name() ,
if the role is admin the urls will become  /admin/manage/view_name().

So basically i want to know how can i access request variable from
middlewares into my main project urls.
I know how to access template context processors but want  to  learn how to
access request in urls.

This is what i have written

url_variable = 'corporate'

for app_name in settings.INSTALLED_APPS:
if not app_name in excluded_apps:
app = get_app(app_name)


#---
# Per module url

#---
for model in get_models(app):
model = model._meta.module_name[5:]
url_path = r"^manage/%s/?$" % (model.lower())
view_name = "admin_manage_%s" % (model.lower())
urlpatterns += patterns('project_name.%s.views' % app_name,
  url(url_path, view_name,
name=view_name),)

Thanks in advance

-- 
Regards
Nikhil Verma
+91-958-273-3156

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: new to Django and building web applications. Advice with postgresql

[Kevin Daum]

On Sunday, May 19, 2013 6:51:09 PM UTC-4, Scott Anderson wrote:
>
>
> I highly recommend *against* waiting for PostgreSQL until deployment. 
> There are significant differences between SQLite, PostgreSQL, and MySQL. If 
> you wait until deployment to test on your production database you will find 
> yourself fixing and changing things at the last minute. Start testing on 
> your production deployment database as soon as possible.
>
>
I'm going to echo Scott's sentiment. I ran into enough 
difficult-to-troubleshoot (or just annoying) issues resulting from 
inconsistencies between sqlite and postgres that I no longer allow my 
developers to use sqlite at all. We now use vagrant to install debian VMs 
running postgres on all our developer machines. We have a shell script that 
automatically creates and configures a database for the project, so it 
doesn't end up taking too much longer to set up than sqlite.

That said, if you're just getting started with django, you probably don't 
want to deal with postgres yet. Feel free to tinker and learn against 
sqlite, but once you start writing code that you're eventually going to put 
into production, I'd start using whatever database you're going to use in 
production.

Kevin 

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: access request variable from middlewares into my main project urls

[Larry Martell]

On Tue, May 21, 2013 at 6:56 AM, Nikhil Verma  wrote:
> Hello Guys
>
>
> I want to make the urls dynamic and change according to roles in the project
> for every app.
> Example if there is role x so it should change like x/manage/view_name() ,
> if the role is admin the urls will become  /admin/manage/view_name().
>
> So basically i want to know how can i access request variable from
> middlewares into my main project urls.
> I know how to access template context processors but want  to  learn how to
> access request in urls.
>
> This is what i have written
>
> url_variable = 'corporate'
>
> for app_name in settings.INSTALLED_APPS:
> if not app_name in excluded_apps:
> app = get_app(app_name)
>
>
> #---
> # Per module url
>
> #---
> for model in get_models(app):
> model = model._meta.module_name[5:]
> url_path = r"^manage/%s/?$" % (model.lower())
> view_name = "admin_manage_%s" % (model.lower())
> urlpatterns += patterns('project_name.%s.views' % app_name,
>   url(url_path, view_name,
> name=view_name),)

I access the request in my middleware, e.g.:

def process_request(self, request):
if self.is_admin_url(request.path) and \
not self.is_admin_url(request.META['HTTP_REFERER']):
request.session['last_site_url'] = request.META['HTTP_REFERER']

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: No styling in Chapter 6 in djangobook

[djingo django]

Thanks, Mike, for your reply.

This turned to be a very common problem...

Following your suggestion, I checked the page source (I am running
Safari browser on OSX 10.8) and indeed saw the references to the CSS
stylesheets:

Site administration | Django site admin



That, as well as your explanation, helped me realize that it was
looking for some STATIC directory, specified by variables such as
STATIC_ROOT or STATICFILES_DIR.

As I am running the built-in Django webserver, using,

   python manage.py runserver

I had expected it to be able to find its own stylesheets, and was
perplexed as to why it was unable to. I checked with the Django
documentation once again, at

https://docs.djangoproject.com/en/dev/howto/static-files/

and noticed that it states:

   Configuring static files

   1. Make sure that django.contrib.staticfiles is included in your
INSTALLED_APPS.

That was it. I uncommented 'django.contrib.staticfiles', and lo and
behold, the admin pages are now styled properly because the
application can now find the STATIC directory containing the required
CSS files.

The Djangobook.com chapter does not mention this step in its
description of how to activate the admin interface

---
Activating the Admin Interface

The Django admin site is entirely optional, because only certain types
of sites need this functionality. That means you’ll need to take a few
steps to activate it in your project.

First, make a few changes to your settings file:

Add 'django.contrib.admin' to the INSTALLED_APPS setting. (The order
of INSTALLED_APPS doesn’t matter, but we like to keep things
alphabetical so it’s easy for a human to read.)
Make sure INSTALLED_APPS contains 'django.contrib.auth',
'django.contrib.contenttypes', 'django.contrib.messages' and
'django.contrib.sessions'. The Django admin site requires these three
packages. (If you’re following along with our ongoing mysite project,
note that we commented out these four INSTALLED_APPS entries in
Chapter 5. Uncomment them now.)


so perhaps that portion of the book should be updated to make certain
that django.contrib.staticfiles' also gets uncommented.

Many thanks for your helpful comments. They led me to finding out how
STATIC files were organized in Django.



On May 20, 10:02 pm, Mike Dewhirst  wrote:
> On 21/05/2013 11:07am, djingo django wrote:
>
>
>
> > I'm starting to learn Django and have been reading through the
> > djangobook.com. I am able to get the code running when  I come to
> > Chapter 6: The Django Admin Site, but it looks nothing like the
> > well-formed and well-styled screenshots in the documentation. The text
> > appears ragged and unstyled.
>
> > Am I missing a CSS stylesheet to make the admin interface line up and
> > get styled properly? How can I fix this?
>
> Yes. If you "View page source" in your browser you should see something
> like this ...
>
> 
>  href="/static/admin/css/dashboard.css" />
>
> So if the stylesheets cannot be found, which web server are you using?
>
> If you are not using the Django dev server, you need to configure your
> web server to look for such static files in a particular location
> (defined in settings.py as STATIC_ROOT) then run "manage.py
> collectstatic" to put them there.
>
> https://docs.djangoproject.com/en/1.5/howto/static-files/
>
>
>
>
>
>
>
>
>
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Django users" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> > an email to django-users+unsubscr...@googlegroups.com.
> > To post to this group, send email to django-users@googlegroups.com.
> > Visit this group athttp://groups.google.com/group/django-users?hl=en.
> > For more options, visithttps://groups.google.com/groups/opt_out.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Django Celery w/ Amazon RDS and Memcached

[Alex Strickland]

On 2013/05/21 02:38 PM, Joey Espinosa wrote:

Nevermind, everyone. Turned out to be simply my fault (had a shell 
connection to the database open). *facepalm*




At the risk of embarrassing myself even more than you were, why is that 
a problem?


--
Regards
Alex

--
You received this message because you are subscribed to the Google Groups "Django 
users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

How to select a django-treebeard node in a form

[Cody Scott]

I have created my tree structure, now I am trying to create a form that 
selects a node which I will use to do some operations.

When I render the form 

class SelectNodeForm(MoveNodeForm):

class Meta:

model = Category


with {{form.as_p}}


I get the fields


Path

Depth

Numchild

Value

Position

Relative to


I would like the form to just contain relative to (but allow multiple 
selection)


Looking at the code here it looks like that field is called 

https://github.com/tabo/django-treebeard/blob/master/treebeard/forms.py


_ref_node_id = forms.TypedChoiceField(required=False,
  coerce=int,
  label=_("Relative to"))

But I cannot render a field that starts with an underscore. "Variables and 
attributes may not begin with underscores: "

So how can I select a django-treebeard node in a form?



-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: new to Django and building web applications. Advice with postgresql

[Simon Riggs]

On 21 May 2013 13:04, Tom Evans  wrote:
> On Sun, May 19, 2013 at 11:51 PM, Scott Anderson
>  wrote:
>> On Sunday, May 19, 2013 11:18:07 AM UTC-4, WongoBongo wrote:
>>>
>>> You don't have to become an expert with postgres to use Django. You can do
>>> most of the db development using SQLite and hold off on postgres until you
>>> are ready to deploy.
>>
>>
>>
>> I highly recommend *against* waiting for PostgreSQL until deployment. There
>> are significant differences between SQLite, PostgreSQL, and MySQL. If you
>> wait until deployment to test on your production database you will find
>> yourself fixing and changing things at the last minute. Start testing on
>> your production deployment database as soon as possible.
>
> The purpose of using an ORM is to make your application database
> agnostic.

ORM stands for Object Relational Mapper. My thinking is that if its
role was solely to make applications database agnostic it would be
called something like Common Database Interface, or Database Agnostic
Layer. Such things do exist, yet so do ORMs. ISTM that ORMs help you
write good applications, not just make things agnostic.

> You should not find that changing DB engine is overly
> taxing.

Hmm, well. A YMMV moment if ever there was one.

> The point is, installing and learning the ins and outs of an RDBMS is
> not necessary to using Django.

Often, yes. But mostly, one needs to consider details about the whole
stack in making things work well.

There are lots of good reasons for careful selection of each part of
your stack. Choosing Django was no doubt an informed decision and one
made with a view to the many good things this gives you. Other
products in your stack benefit from similar careful and informed
decision making.

Otherwise we'd all be using microCOBOL on Netware.

> If you think you are stuck trying to
> install or understand postgres, just ignore it and use sqlite. You can
> always change at a later date.

Changing a major architectural component in your stack is not a
trivial thing. Major changes affect the quality of your deliverables.

The most important thing is that a database is a shared resource. If
you write all your programs assuming you'll be the only user then it
likely won't work very well in production.

--
 Simon Riggs   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: new to Django and building web applications. Advice with postgresql

[Tom Evans]

On Tue, May 21, 2013 at 2:16 PM, Simon Riggs  wrote:
> On 21 May 2013 13:04, Tom Evans  wrote:
>> On Sun, May 19, 2013 at 11:51 PM, Scott Anderson
>>  wrote:
>>> On Sunday, May 19, 2013 11:18:07 AM UTC-4, WongoBongo wrote:

 You don't have to become an expert with postgres to use Django. You can do
 most of the db development using SQLite and hold off on postgres until you
 are ready to deploy.
>>>
>>>
>>>
>>> I highly recommend *against* waiting for PostgreSQL until deployment. There
>>> are significant differences between SQLite, PostgreSQL, and MySQL. If you
>>> wait until deployment to test on your production database you will find
>>> yourself fixing and changing things at the last minute. Start testing on
>>> your production deployment database as soon as possible.
>>
>> The purpose of using an ORM is to make your application database
>> agnostic.
>
> ORM stands for Object Relational Mapper. My thinking is that if its
> role was solely to make applications database agnostic it would be
> called something like Common Database Interface, or Database Agnostic
> Layer. Such things do exist, yet so do ORMs. ISTM that ORMs help you
> write good applications, not just make things agnostic.

Opinions. We've all got them. Django's one line description of their ORM:

  Django provides an abstraction layer (the “models”) for structuring
and manipulating the data of your Web application.

Django's abstraction layer provides a bunch of features, all of which
operate identically across a variety of database servers. Its an
abstraction layer that provides database agnostic features.

ISTM you're being overly pedantic.

>
>> You should not find that changing DB engine is overly
>> taxing.
>
> Hmm, well. A YMMV moment if ever there was one.

This comment was directed at the OP. The OP is just starting to use
any web development package, anything he does in Django with sqlite
should be easily switched to another database. Do you have some
examples of Django features he would find difficulty with if he
switched from using django/sqlite to django/postgres?

I know you do a lot of Postgresql consulting, I expect some of this
may involve migrating MySQL -> Postgres, and if you have an
application written for MySQL, it will be tricky porting it over.
However, this is not that scenario.

The only queries you need to rewrite on moving django/sqlite ->
django/postgres are raw queries. How many will this beginner have?
Should rewriting raw queries be the thing this beginner worries about?

'YMMV' indeed. Switching or changing DB engines in a Django app is not
hard, unless the app is extremely badly written.

>
>> The point is, installing and learning the ins and outs of an RDBMS is
>> not necessary to using Django.
>
> Often, yes. But mostly, one needs to consider details about the whole
> stack in making things work well.
>
> There are lots of good reasons for careful selection of each part of
> your stack. Choosing Django was no doubt an informed decision and one
> made with a view to the many good things this gives you. Other
> products in your stack benefit from similar careful and informed
> decision making.
>
> Otherwise we'd all be using microCOBOL on Netware.

Yes. I'm sure the OP is also making a pro/con list to decide which of
gunicorn and Tornado to use.

>
>> If you think you are stuck trying to
>> install or understand postgres, just ignore it and use sqlite. You can
>> always change at a later date.
>
> Changing a major architectural component in your stack is not a
> trivial thing. Major changes affect the quality of your deliverables.

The most important thing as a beginner developer is to start
developing things, and don't get distracted by irrelevancy. Messing
about getting the perfect Postgresql install will not get you any
further with being able to develop websites in Django, and seeing as
that is what the OP wanted to do, if postgresql is a problem for him,
he should ignore it, and start the work he wanted to do.

You do not need postgresql to develop in Django, just like you don't
need Apache/mod_wsgi. The simplest, easiest and most straightforward
way is to use sqlite as your database, and to serve pages using
runserver.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

problem with extending django registration form

[Okorie Emmanuel]

hi

I have tried extending django registration page with little progress.
I can now add new user from the admin but cannot do that on the 
front end. the problem is that the url does not display the from,
but raises exception, "the page cannot be found". Do I need to create a 
view.py
to be able to use  django registration app?

here is my code

http://pastebin.com/JBa8J1ry

is there anything i have not done right?

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: new to Django and building web applications. Advice with postgresql

[Simon Riggs]

On 21 May 2013 15:00, Tom Evans  wrote:

> The only queries you need to rewrite on moving django/sqlite ->
> django/postgres are raw queries. How many will this beginner have?
> Should rewriting raw queries be the thing this beginner worries about?
>
> 'YMMV' indeed. Switching or changing DB engines in a Django app is not
> hard, unless the app is extremely badly written.

Changing the engine is not hard, but that doesn't mean it will work
exactly as expected.

There are many operational aspects to consider and changing a major
component at the last minute isn't good practice, whether that be
Postgres, sqlite or any other component.

Whatever you plan to use, please use it from the start. If you can.

If there are blockers to doing that for Postgres, please mention it to
me, other community members or on the Postgres lists, so we can help.

--
 Simon Riggs   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Understanding Django transactions

[John DeRosa]

Regardless of whatever comments and corrections may come, I thank you for 
summarizing what you think the changes will be! I didn't know about these 
impending changes.

John

On May 21, 2013, at 4:23 AM, Michael  wrote:

> 
> I've been reading up on how transactions work in Django 1.5 and how they will 
> work in 1.6. I think I have a grasp of things, but I wanted to reach out on 
> here to just check that my understanding of things is correct, and ask a 
> question or two.
> 
> Django 1.5:
> 
> The database-level auto-commit is turned OFF.
> SQL standards dictate that every query opens a transaction if one does not 
> already exist. This happens regardless of the database's auto-commit setting.
> After each Django ORM operation (read or write), Django commits this open 
> transaction. This emulates the database-level auto-commit.
> Transaction decorators cannot be nested. When one is opened, any previous 
> transaction will be committed.
> When executing raw SQL (with a database cursor), Django marks the current 
> transaction as dirty but does not issue a commit. If data changes were made 
> then they need manually committing. Why do the docs say that you only need to 
> commit the change if data was changed? If the transaction is marked as dirty 
> regardless of a read or a write, would it not always need committing or 
> rolling back to ensure the transaction is properly closed by the end of the 
> connection?
> Setting TRANSACTIONS_MANAGED to True stops Django from sending any commits 
> after ORM operations. The database-level auto-commit is still disabled. With 
> this setting, using any Django ORM read or write operation (all wrapped in 
> `transaction.commit_on_success`) fails with TransactionManagementError('This 
> code isn't under transaction management'). Is this expected?
> Django 1.6:
> 
> The database-level auto-commit is turned ON.
> Every database operation via the ORM will be committed using the database's 
> auto-commit, including any custom SQL executed with the database cursor.
> The `atomic` decorator / context manager either starts a new transaction, or 
> creates a new savepoint if it's nested within an existing transaction. They 
> are committed as long as no exception is raised.
> If ATOMIC_REQUESTS is specified in the database config, all views are wrapped 
> in `atomic`, unless it's wrapped in `non_atomic_requests`.
> If you set AUTOCOMMIT to False in a database configuration, this will disable 
> the database-level auto-commit. All DB reads and writes will need manually 
> wrapping in transactions. The docs say that with this disabled, Django won't 
> perform any commits. Does this mean that the `atomic` decorator won't work 
> properly and you have to use the underlying database library to handle 
> transactions? In 1.6 it would appear that Django never performs a commit 
> outside of `atomic`, so I'm confused by this comment!
> I'd really appreciate any information if some of what I understand to be true 
> is not accurate.
> 
> Many thanks!
> 
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-users?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>  
>  

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Pickling of dinamically created models.Model subclasses: "attribute lookup failed", django 1.5

[akaariai]

I have finally found the time to work on this issue. There is a patch
in the ticket (https://code.djangoproject.com/ticket/20289), and I
think the patch does solve the regression.

I didn't find a simple test case that works in 1.4 but fails in 1.5.
If anybody knows how to reproduce the original regression that would
be very useful in ensuring the regression is really solved.

 - Anssi


On 19 huhti, 02:06, akaariai  wrote:
> On 18 huhti, 22:07, Greg H  wrote:
>
> > Running into a similar issue on my own project, seems to be when you try an
> > cache a model which has a related model which in turn has a many to many
> > field. So for example, I have an instance of a Student, which has a
> > ForeignKey to Book, which in turn has a ManyToMany to Author. If I try and
> > cache my Student instance, I get that pickling error. In Django 1.4 it
> > worked fine, but not in 1.5.
>
> > Figure out a resolution to this?
>
> The problem is that for an instance of a class to be picklable the
> class must be available as a module level attribute somewhere. For
> dynamically created classes this is usually not true - they aren't
> available at module level. One set of such classes is automatically
> created through models for m2m fields. The automatic through classes
> could explain the ManyToMany problem.
>
> All in all this looks like a regression that should be fixed in 1.5. I
> created a ticket for this, see:https://code.djangoproject.com/ticket/20289
>
>  - Anssi

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Object Lookup after Save

[Chris Conover]

Hello,

I'm having an issue looking up objects immediately after they are saved and 
am wondering if anyone has any advice on how to address the problem. 
Specifically, I'm saving an object in a view (nothing fancy, a simple 
save()) and then kicking off a Gearman task to do some operations on that 
saved object in the background. I pass the newly created object's PK as 
data to the Gearman worker which then does a simple 
Objects.objects.get(pk=PK). However, almost all of the time this lookup 
operation fails with an DoesNotExist exception. I believe the problem has 
to do with transactions. Namely, the read in the Gearman worker is 
happening before the write from the view is committed to the database. I've 
tried several things including refactoring the saving code to be wrapped in 
a @transaction.commit_on_success block, moving the worker submission to 
post_save and adding a long delay before the Gearman worker does the 
lookup. Nothing really seems to solve the problem completely. Even with a 
60 second delay, the lookup fails with some frequency. Am I missing 
something here? Is there some Django query cache that I can clear? Or 
should I just rewrite all this to just to use a look-back perspective.

The stack is Django 1.4 connecting to MySQL 5.5.27. Django is handling 
200-1000 requests per second and the database is handling about double that.

Thanks,
Chris

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Django Celery w/ Amazon RDS and Memcached

[Joey Espinosa]

Sorry, just saw this. Presumably I had some sort of lock on the database
which was preventing the async task from reloading a database dump. As soon
as I exited the database shell, the task finished successfully.

--
Joey "JoeLinux" Espinosa*
*




On Tue, May 21, 2013 at 9:08 AM, Alex Strickland  wrote:

> On 2013/05/21 02:38 PM, Joey Espinosa wrote:
>
>  Nevermind, everyone. Turned out to be simply my fault (had a shell
>> connection to the database open). *facepalm*
>>
>>
> At the risk of embarrassing myself even more than you were, why is that a
> problem?
>
> --
> Regards
> Alex
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to 
> django-users+unsubscribe@**googlegroups.com
> .
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at 
> http://groups.google.com/**group/django-users?hl=en
> .
> For more options, visit 
> https://groups.google.com/**groups/opt_out
> .
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

timezone.activate GMT+offset inverts

[Avraham Serour]

Hi,

I have created a middleware that calls timezone.activate like this:

from pytz import timezone as tz
timezone.activate(tz('Etc/GMT+3'))

I when printing the time 20:20 UTC+0 it shows as 17:20

I even tried to use

{% timezone "Etc/GMT+3" %}
{{ value }}
{% endtimezone %}

but it still shows 17:20 when it should show 23:20
of course if I use
{% timezone "Etc/GMT-3" %}
{{ value }}
{% endtimezone %}

it shows the correct time. is there a bug when using GMT+offset timezone
instead of the regular Zone/Country

if anyone is wondering why I am doing this let me try to explain myself.
When a user logs in using facebook I can get the timezone from the
extra_data, facebook calculates DST and returns a number

thanks
avraham

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Understanding Django transactions

[Aymeric Augustin]

Hi Michael,
 
>
> *Django 1.5:*
>

>- The database-level auto-commit is turned OFF.
>
> Yes. 

>
>- SQL standards dictate that every query opens a transaction if one 
>does not already exist. This happens regardless of the database's 
>auto-commit setting.
>
> Yes, this is required by PEP 249 and taken care of by the database 
adapter. 

>
>- After each Django ORM operation (read or write), Django commits this 
>open transaction. This emulates the database-level auto-commit.
>
> No, transactions are only committed after write operations, so it isn't 
exactly like database-level autocommit. 

>
>- Transaction decorators cannot be nested. When one is opened, any 
>previous transaction will be committed.
>
>  Not necessarily. It's complicated. It depends on the previous state (auto 
/ managed), the current state (auto / managed) and the dirty flag.

I never understood the logic. Your best chance is to read the source if you 
really need to know how it works.

>
>- When executing raw SQL (with a database cursor), Django marks the 
>current transaction as dirty but does not issue a commit. If data changes 
>were made then they need manually committing. *Why do the 
> **docs*
>* say that you only need to commit the change if data was changed? If 
>the transaction is marked as dirty regardless of a read or a write, would 
>it not always need committing or rolling back to ensure the transaction is 
>properly closed by the end of the connection?*
>
> In Django 1.2 and earlier, the connection wasn't marked dirty on raw SQL 
operations. If you didn't commit and you didn't perform any other writes 
until the end of the query, Django would issue a rollback.

In Django 1.3-1.5, I'm not sure what happens exactly. I believe the 
transaction management will always issue a commit or a rollback before the 
connection is aborted and closed by the request_finished signal, but I 
could be wrong.

Honestly, when I rewrote transaction management, no one understood how it 
interacted with the dirty flag. So I can't answer this question and I don't 
think anyone else can. Once again, read the source if you need to know how 
it works in a specific case.

>
>- Setting TRANSACTIONS_MANAGED to True stops Django from sending any 
>commits after ORM operations. The database-level auto-commit is still 
>disabled.* With this setting, using any Django ORM read or write 
>operation (all wrap**ped in `transaction.commit_on_success`) fails 
>with TransactionManagementError('This code isn't under transaction 
>management'). Is this expected?*
>
> I have no idea.

>
>
> *Django 1.6:*
>
>- The database-level auto-commit is turned ON. 
>- Every database operation via the ORM will be committed using the 
>database's auto-commit, including any custom SQL executed with the 
> database 
>cursor. 
>- The `atomic` decorator / context manager either starts a new 
>transaction, or creates a new savepoint if it's nested within an existing 
>transaction. They are committed as long as no exception is raised. 
>- If ATOMIC_REQUESTS is specified in the database config, all views 
>are wrapped in `atomic`, unless it's wrapped in `non_atomic_requests`.
>
> Yes, these four sentences are correct. 

>
>- If you set AUTOCOMMIT to False in a database configuration, this 
>will disable the database-level auto-commit. All DB reads and writes will 
>need manually wrapping in transactions. *The 
> **docs*
>* say that with this disabled, Django won't perform any commits. Does 
>this mean that the `atomic` decorator won't work properly and you have to 
>use the underlying database library to handle transactions? In 1.6 it 
> would 
>appear that Django never performs a commit outside of `atomic`, so I'm 
>confused by this comment!* 
>
> First, it's extremely unlikely that you will ever need to set AUTOCOMMIT 
to False. This is only useful if you want to implement your own transaction 
management, and I don't know anyone who's done that, nor a use case for 
doing that. I'd be surprised if this discussion was relevant to a single 
person on this mailing list (but I've been surprised before!). Also, your 
link goes to the 1.5 docs, not the dev docs. This may have confused you.

Anyway, in this scenario, `atomic` will work as expected. When autocommit 
is off, you're always in a transaction, and as a consequence `atomic` uses 
savepoints to guarantee atomicity; it'll never commit. You have to call 
transaction.commit() at some point to save changes.

I hope that helps,

-- 
Aymeric.

PS: If you weren't at DjangoCon Europe, you might want to check my talk on 
this topic. Slides are at 
http://static.myks.org/data/20130517-DjangoCon-Transactions.pdf and the 
vid

Re: Object Lookup after Save

[Tom Evans]

On Tue, May 21, 2013 at 4:23 PM, Chris Conover  wrote:
> Hello,
>
> I'm having an issue looking up objects immediately after they are saved and
> am wondering if anyone has any advice on how to address the problem.
> Specifically, I'm saving an object in a view (nothing fancy, a simple
> save()) and then kicking off a Gearman task to do some operations on that
> saved object in the background. I pass the newly created object's PK as data
> to the Gearman worker which then does a simple Objects.objects.get(pk=PK).
> However, almost all of the time this lookup operation fails with an
> DoesNotExist exception. I believe the problem has to do with transactions.
> Namely, the read in the Gearman worker is happening before the write from
> the view is committed to the database. I've tried several things including
> refactoring the saving code to be wrapped in a
> @transaction.commit_on_success block, moving the worker submission to
> post_save and adding a long delay before the Gearman worker does the lookup.
> Nothing really seems to solve the problem completely. Even with a 60 second
> delay, the lookup fails with some frequency. Am I missing something here? Is
> there some Django query cache that I can clear? Or should I just rewrite all
> this to just to use a look-back perspective.
>
> The stack is Django 1.4 connecting to MySQL 5.5.27. Django is handling
> 200-1000 requests per second and the database is handling about double that.
>
> Thanks,
> Chris

  from django import transaction
  …
  obj.save()
  transaction.commit()
  task.submit(obj.id)

You will also need to make sure that gearman is doing things correctly
as well. You haven't mentioned what database you are using, but if
gearman's DB connection is in a read repeated mode, you can do
whatever you like in django but you won't see new data in gearman
until gearman's current transaction is committed.

Cheers

Tom

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

How to locate django extension templates

[Cody Scott]

I am trying to use django-treebeard in the admin.

https://tabo.pe/projects/django-treebeard/docs/tip/intro.html#configuration

It says 

Note
 

If you are going to use the 
Treeadmin
 class, 
you need to add the path to treebeard’s templates in 
TEMPLATE_DIRS.
 
Also you need to 
enabledjango.core.context_processors.request
 in 
the 
TEMPLATE_CONTEXT_PROCESSORSsetting
 
in your django settings file.


How do I find where the templates for django-treebeard are located?



-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

define BASE_DIR?

[Christopher Spears]

I am working my way through the Django tutorial, and I have reached the 
part where I am supposed to customize the look and feel of the admin.  I am 
supposed to do that using the mysite\settings.py file (working on a Windows 
laptop).  I have two questions.

At first, I just typed the following into the file:

TEMPLATE_DIRS = [os.path.join(BASE_DIR, 'templates')]

I got an error message stating that os.path was not recognized.  I solved 
this by putting 'import os.path' at the top of the file.  Does this mean 
there is a bug in the tutorial's documentation?  I do not recall seeing any 
instructions that told me to add this.

After I solved the first problem, I now get this error message:

  File "C:\Users\Chris\Documents\django_dev\mysite\mysite\settings.py", 
line 7,
in 
TEMPLATE_DIRS = [os.path.join(BASE_DIR, 'templates')]
NameError: name 'BASE_DIR' is not defined

Am I supposed to now define BASE_DIR?

Thanks!

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: define BASE_DIR?

[Charly Román]

2013/5/21 Christopher Spears :
> I am working my way through the Django tutorial, and I have reached the part
> where I am supposed to customize the look and feel of the admin.  I am
> supposed to do that using the mysite\settings.py file (working on a Windows
> laptop).  I have two questions.
>
> At first, I just typed the following into the file:
>
> TEMPLATE_DIRS = [os.path.join(BASE_DIR, 'templates')]
>
> I got an error message stating that os.path was not recognized.  I solved
> this by putting 'import os.path' at the top of the file.  Does this mean
> there is a bug in the tutorial's documentation?  I do not recall seeing any
> instructions that told me to add this.
>
> After I solved the first problem, I now get this error message:
>
>   File "C:\Users\Chris\Documents\django_dev\mysite\mysite\settings.py", line
> 7,
> in 
> TEMPLATE_DIRS = [os.path.join(BASE_DIR, 'templates')]
> NameError: name 'BASE_DIR' is not defined
>
> Am I supposed to now define BASE_DIR?
>
> Thanks!
>

You need to define BASE_DIR, for example:

BASE_DIR = os.path.dirname(os.path.realpath(__file__))

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

theme generator

[Kakar Arunachal Service]

Hi!
Is there any kind of theme generator or css generator for django?

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Object Lookup after Save

[Chris Conover]

Calling transaction.commit() after object.save results in 
a TransactionManagementError. I mentioned at the end that I am using MySQL 
(5.5.27). The issue is not that the Gearman workers are having trouble 
saving their transactions, it's that they are having trouble looking up the 
incoming object. I'm assuming the view and workers are separate 
transactions since I don't see how they could be connected -- though I'm 
looking into this. 

On Tuesday, May 21, 2013 1:05:54 PM UTC-4, Tom Evans wrote:
>
> On Tue, May 21, 2013 at 4:23 PM, Chris Conover 
> > 
> wrote: 
> > Hello, 
> > 
> > I'm having an issue looking up objects immediately after they are saved 
> and 
> > am wondering if anyone has any advice on how to address the problem. 
> > Specifically, I'm saving an object in a view (nothing fancy, a simple 
> > save()) and then kicking off a Gearman task to do some operations on 
> that 
> > saved object in the background. I pass the newly created object's PK as 
> data 
> > to the Gearman worker which then does a simple 
> Objects.objects.get(pk=PK). 
> > However, almost all of the time this lookup operation fails with an 
> > DoesNotExist exception. I believe the problem has to do with 
> transactions. 
> > Namely, the read in the Gearman worker is happening before the write 
> from 
> > the view is committed to the database. I've tried several things 
> including 
> > refactoring the saving code to be wrapped in a 
> > @transaction.commit_on_success block, moving the worker submission to 
> > post_save and adding a long delay before the Gearman worker does the 
> lookup. 
> > Nothing really seems to solve the problem completely. Even with a 60 
> second 
> > delay, the lookup fails with some frequency. Am I missing something 
> here? Is 
> > there some Django query cache that I can clear? Or should I just rewrite 
> all 
> > this to just to use a look-back perspective. 
> > 
> > The stack is Django 1.4 connecting to MySQL 5.5.27. Django is handling 
> > 200-1000 requests per second and the database is handling about double 
> that. 
> > 
> > Thanks, 
> > Chris 
>
>   from django import transaction 
>   … 
>   obj.save() 
>   transaction.commit() 
>   task.submit(obj.id) 
>
> You will also need to make sure that gearman is doing things correctly 
> as well. You haven't mentioned what database you are using, but if 
> gearman's DB connection is in a read repeated mode, you can do 
> whatever you like in django but you won't see new data in gearman 
> until gearman's current transaction is committed. 
>
> Cheers 
>
> Tom 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: theme generator

[Aaron C. de Bruyn]

Not specifically, but Bootstrap is nice:

http://twitter.github.io/bootstrap/



On Tue, May 21, 2013 at 2:19 PM, Kakar Arunachal Service <
kakararunachalserv...@gmail.com> wrote:

> Hi!
> Is there any kind of theme generator or css generator for django?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-users?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: new to Django and building web applications. Advice with postgresql

[Scott Anderson]

On May 21, 2013, at 8:04 AM, Tom Evans wrote:
> 
> The purpose of using an ORM is to make your application database
> agnostic. You should not find that changing DB engine is overly
> taxing.

Theoretically, yes. The difference between theory and practice is very small in 
theory, and not so much in practice. ;-)

Theoretically, the ORM should protect you from differences between databases. 
In practice, this doesn't always happen. 

There *are* real world differences between running different databases on the 
same ORM. Quoting the purpose of an ORM and telling someone they "should not" 
have a problem is naive, sorry.

While some of these differences can be avoided, doing so requires the developer 
to know that they exist in the first place, thus negating the purpose of using 
an ORM. Given the character of the question by the original poster, I suspect 
he might have issues with this.

PostgreSQL is very strict by default. SQLite is very forgiving. 

You can also run into problems with South migrations working on one and not the 
other.


> Not all of these statements are wholly accurate, mysql will re-use
> keys when necessary (but doesn't try to 'back fill' the set of used
> ids), and

The statements don't need to be "wholly accurate". The behavior is different in 
practice.


> mysql is also perfectly happy with 0 as a primary key, but
> will replace it with the next auto increment id if the field is an
> auto increment field.

class Moo(models.Model):
name = models.CharField(max_length=50)

moo.json:
[
{
"pk": 0,
"model": "test.moo",
"fields": {
"name": "Test"
}
}
]

Running as MySQL:
anderson$ python manage.py loaddata moo.json
ValueError: Problem installing fixture 
'/Users/anderson/src/.../fixtures/moo_genre.json': The database backend does 
not accept 0 as a value for AutoField.

Running as Sqlite:
anderson$ python manage.py loaddata moo.json
Installed 1 object(s) from 1 fixture(s)

If your real world dataset includes a row with 0 as the primary key, you need 
to be aware of this.

> There is no 'natural ordering' of un-ordered
> results, the order is undefined, and undefined behaviour is undefined.

In theory, yes. However, the naive developer may observe that this ordering is 
actually implementation-specific under the hood and write code based on that 
fact, and in doing so tie the code to a particular implementation. Yes, you 
should always include an order_by if your use case depends on ordering. No, not 
everyone realizes that.


> The point is, installing and learning the ins and outs of an RDBMS is
> not necessary to using Django. If you think you are stuck trying to
> install or understand postgres, just ignore it and use sqlite. You can
> always change at a later date.

And my point is that there remain ins and outs of the various database backends 
that prevent seamless migration between them.

At some point you will need to install and test on your production database. 
Why not do it first and avoid possible incompatibilities between dev and 
production down the way?

If you're just learning, that's fine. No need. But as soon as you're on an 
actual project, do yourself a favor and develop on the platform you plan on 
using in production.

Regards,
-scott

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.