Re: Switch to database-level autocommit

[kayess]

On Wednesday, 6 March 2013 16:12:18 UTC+7, jdunck wrote:
>
> Can 
> you give a concrete example of an exception being raised at commit 
> time? 
>

Postgres allows for things like foreign key integrity checks to be made on 
commit (rather than when the data is entered). This makes it significantly 
easier to enter data where there is a circular dependency, and also reduces 
the amount of time certain locks are held. Django makes use of this feature.


Kirit

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

Re: Thoughts on defining and autoimporting signals.py

[kayess]

On Jan 19, 8:44 pm, Emil Stenström  wrote:
> On Thursday, 22 December 2011 03:49:44 UTC+1, Russell Keith-Magee wrote:
> > ... there isn't a single solution that will work
> > everywhere, which one of the reasons that the docs are silent on the
> > issue.
>
> Just for the record: The docs are actually telling you to put your signals
> in models.py, at the end 
> of:https://docs.djangoproject.com/en/dev/topics/signals/#s-receiver-func...
>
> I would much rather have them point people to signals.py, and an import
> signals.py in __init__.py. I've seen beginners be trapped in the circular
> import loop when trying to move their signals to a separate file, not
> realizing that they also need to move the import of signals.py away from
> models to be able to use Model classes inside signals.

The problem with importing them from __init__.py is that it breaks
coverage as the signals and the models get imported before the
coverage tools are loaded when using things nose, django nose and nose
coverage.


Kirit

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

Re: Multiple timezone support for datetime representation

[kayess]

I just wanted to chime in with a couple of extra notes here. I won't
comment on most of it as I think it's all spot on :)

On Sep 3, 10:40 pm, Aymeric Augustin
 wrote:
> Django should use timezone-aware UTC datetimes internally
> .
>
> Example : datetime.datetime(2011, 09, 23, 8, 34, 12, tzinfo=pytz.utc)

There is also a Django time field. How to handle this is kind of hard
as having a timezone on a time field may not make much sense. At the
moment it is up to application code to combine this with a date in a
sane manner. If Django switches to use UTC internally then this is
going to become harder for many users to do correctly. Maybe some
library functions that will help them to do this will work?

Using UTC internally isn't enough in the way that using Unicode
internally is to mean that application writers can factor out time
handling in global applications. For example, if I have a Django
application that tracks retail sales worldwide then a report of sales
figures for any given day probably needs to use the correct local time
at each store to make sense from a business perspective. Using UTC
internally may however make developers aware that there is an issue
for them address earlier -- a good thing.


The other thing that ought to be thought about with this is the admin
time/date widgets which have the 'now' link. This is always filled in
with the browser's current time which plays havoc when admin is used
by a user in a different time zone to the site's settings. It should
be possible to capture the UTC offset along with the time so that the
correct number of minutes is added/subtracted when the field is
processed by Django. Thankfully daylight savings can be ignored here.

Many browsers will send the local time of the request to the server.
This can be used to guess the correct timezone, but it won't get
things right (there's no way to work out the correct DST setting from
this). If the country can be identified in some way then the two
together should be good for most users. The UTC offset in the request
is all that's needed to get localize any times that are sent back
though as again, daylight savings can be ignored -- so long as we
aren't rash enough to presume that this offset tells us the actual
time zone.

Hope this is useful,


Kirit

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

Re: #13870: Correctly handling database isolation (in PostgreSQL)

[kayess]

Strange. We use Postgres and don't see any problem with this. We do
encounter complications occasionally with the lack of composition of
Django transaction handling, but other than that find the transaction
handling adequate.

Are you actually using transactions in your code? You need to be. The
transaction middleware does a good enough job for most things, but for
external processing you will need to carefully design your transaction
handling. With the transaction middleware we see fully isolated
updates until the transaction is committed using psycopg2.


Kirit

On Sep 5, 6:52 pm, Patryk Zawadzki  wrote:
> The problem is that this is not true for Django. The backend
> initializes the meta-transaction at connection time and never bothers
> to terminate it. As the transaction is merely a ghost-read-preventing
> one, it does not stop data from being saved in the database, but it
> does result in a parmanently open transaction. This both wastes
> resources on the server and prevents any other client from touching
> the database structure (any ALTER or VACUUM command will hang waiting
> for the remaining transactions to finish).
>
> The ticket contains a naïve workaround but as described there, I feel
> a proper solution would look like this:
>
> 1. Introduce IsolationMiddleware that does something like this (pseudocode):

[snip]

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Object Relational Mapping and REST Web Services in Django

[kayess]

On Feb 12, 10:35 pm, rpst...@gmail.com wrote:
> Greetings Django Developers,
>
> Allow me to introduce myself; my name is Rory Tulk.  I'm a grad
> student at the University of Toronto.  A small team of students and I
> are investigating possible implications of unifying the process of
> specifying object relational mapping configuration and URL & function
> mapping for REST web services, and are intending on using Django as
> our target platform for prototyping.  As a starting point, I'd like to
> elicit opinions from the community on directions this could go in.
> Are there any feature requests outstanding for Django's ORM or Web
> Service support?  Any known pitfalls?

We've been doing a fair bit of this sort of thing for a project we're
just finishing. Ours is probably more RESTlike than RESTful though :)
We've done a lot of thinking around how to map function calls to URLs.
Our user interfaces use the same ideas too.

Personally I've always felt that there are very clear ways to map
function calls to URLs. There's many ways of doing it, path
specification for positional arguments, query string for named
arguments for example. We're designing a functional programming
language using these ideas to experiment with (although we're using
Google's App Engine rather than Django for that, but all the clever
bits would work perfectly well on either).

The first part we've started to document is the service
authentication. You can read something about that at:
http://www.kirit.com/Using%20Django%20within%20ASP.NET%20web%20sites

We also have our own web app framework (Windows only at the moment
sadly) which is architected a little bit differently than Django and
some of those differences make a difference to this sort of handling.
The primary difference is that our O/RM is higher level than Django's
ActiveRecord based design (there are pros and cons to both) which
enables us to process things in a more uniform manner. We're currently
porting this to Linux/Python/Django but it will take some time before
there's anything other than a few low level components available.


K

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---