Re: db backend refactoring
On Sun, 2007-08-19 at 23:01 -0500, Adrian Holovaty wrote: [...] > I haven't yet made DatabaseError, IntegrityError and the introspection > and creation functionality accessible via the django.db.connection > object. Those changes can happen in the near future, if they need to > be made. If we do move those (not clear why it would be needed, though), it'd be nice to leave backwards compat references in place. We pull out those exceptions into a db-neutral namespace because people are using them a lot. So changing it will have a big impact and leaving an alias in place is free. > Note that this is backwards-incompatible for anybody who was using the > django.db.backend functions -- such as quote_name() -- directly. None > of this stuff was documented, so I don't see it as a *huge* deal, but > we can add backwards-compatibility hooks for some of the most common > actions (quote_name() comes to mind) if people feel like that's > important. I've outlined the changes here: > > http://code.djangoproject.com/wiki/BackwardsIncompatibleChanges#Refactoreddatabasebackends Looking at that list of renamed functions, the only one that jumps out as likely to be generically used is quote_name. If you're trying to write custom SQL, particularly database-agnostic custom SQL, it's a handy function to use. The majority of the list are internal implementation details and not useful outside of Django. In fact, about half of them didn't exist before early this year (test framework and Oracle added a lot of per-database tests). > A big thanks to Brian for his work on the design and implementation of > this refactoring. Ditto. Thanks, Brian. Thanks for doing the review and committing here, too, Adrian. Cheers, Malcolm -- Experience is something you don't get until just after you need it. http://www.pointy-stick.com/blog/ --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: db backend refactoring
On 8/13/07, Brian Harring <[EMAIL PROTECTED]> wrote: > As hinted at earlier on the ml, have started doing some work on > refactoring the actual db backend; ticket 5106 holds the current > version (http://code.djangoproject.com/ticket/5106). I've implemented pretty much all of this in a flurry of commits this afternoon/evening. See http://code.djangoproject.com/ticket/5106 for a list of the relevant commits (as ticket comments). I haven't yet made DatabaseError, IntegrityError and the introspection and creation functionality accessible via the django.db.connection object. Those changes can happen in the near future, if they need to be made. Note that this is backwards-incompatible for anybody who was using the django.db.backend functions -- such as quote_name() -- directly. None of this stuff was documented, so I don't see it as a *huge* deal, but we can add backwards-compatibility hooks for some of the most common actions (quote_name() comes to mind) if people feel like that's important. I've outlined the changes here: http://code.djangoproject.com/wiki/BackwardsIncompatibleChanges#Refactoreddatabasebackends A big thanks to Brian for his work on the design and implementation of this refactoring. Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
COVER LETTERS RESUME EXAMPLES AND CV EXAMPLES AVAILABLE CURRICULUM VITAE
Resumes and CV's examples written by people in the industry. They are the ones who know best what to write in a resume for that industry. High Tech people writing technical resumes and CV examples, and Teachers writing and advising teaching resumes examples and CV examples. Do you really want a FREE example written by someone who has never been a teacher or someone who has never been in High Tech? Cover Letter is included. Experienced High Tech Resumes and CVs as well as teacher resumes and CV's. 21 Years High Tech Experience in Development, QA, Test, and Support. Extensive Experience in writing Teacher Resumes also. NEW INFORMATION REGARDING VIDEO RESUMES AND ALSO THE INTERNET. www.resumewritersguide.com http://www.resumewritersguide.com/resumeexampur.htm --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Adding hooks to methods that generate SQL in django/core/management.py
Russell Keith-Magee wrote:
> On 8/13/07, George Vilches <[EMAIL PROTECTED]> wrote:
>> Russell Keith-Magee wrote:
>>> The configuration option will need to be a little more generic - i.e.,
>>> putting the entire backend into a record mode - not just a single
>>> cursor call.
>> Second, we could add a class level variable to each DatabaseWrapper,
>> since the handle to those seem to be instantiated only once at runtime
>> (at least, my short testing with just the Django built-in webserver
>> seemed to do so, I only assume that for Apache it's once per thread).
>> That would be an easy enough variable to update from pretty much
>> anywhere in the app:
>>
>> connection.playback_only = True
>
> There's another possibility you haven't considered - dynamically
> replacing/wrapping the connection object. The test system already does
> this for the email framework - when the test framework is set up, the
> email framework is dynamically replaced with a mock; when the test
> framework is torn down, the mock is uninstalled. A similar approach
> could be used to 'start/end SQL recording'.
Since Adrian has done great work tonight landing Brian Harring's
database refactoring, it seemed like a good time to revisit this,
because dropping the addition of "non-executing" or "playback only" SQL
(what do we want to call this?) will be in a single place and very painless.
As far as dynamically wrapping it, that's a neat idea, and I think it
would have been very appropriate before the refactor. Now, we've
already got a debug cursor, and we're already tracking queries, so the
change seems very natural.
The two needed file patches are at the bottom of the e-mail. This
change is small and totally non-destructive to existing apps. If you
want to turn your DB to playback_only, you just have to call:
from django.db import connection
connection.playback_only = True
And since the connection variable are only be initialized once per
runtime, setting it once anywhere means that the app is in playback only
mode for the rest of the run. This could easily be controlled from a
middleware, so all the items below this middleware could be playback
only, but outer middlewares can still write to the database if necessary.
The only way this could be simpler or easier for the user to control is
if there was an entry in settings.py that the user could also use.
settings.DATABASE_PLAYBACK_ONLY, maybe? I'm only +0 on this. It would
have to be optional, because I can definitely see a reason for wanting
to turn this ability on and off during runtime without changing the code
at all. Specifically, I could imagine several setup programs in the
style of phpBB (I know, it's a sin to mention PHP apps on here, but
everything I can think of right this second is in PHP) that might want
to turn it off based on whether the user asked to display the queries or
actually execute them on install on the previous web page.
How do people feel about this approach?
Thanks,
gav
--- django_orig/django/db/backends/__init__.py 2007-08-19
21:22:44.0 -0400
+++ django_live/django/db/backends/__init__.py 2007-08-19
22:03:11.0 -0400
@@ -12,6 +12,7 @@ class BaseDatabaseWrapper(local):
ops = None
def __init__(self, **kwargs):
self.connection = None
+self.playback_only = False
self.queries = []
self.options = kwargs
@@ -31,13 +32,13 @@ class BaseDatabaseWrapper(local):
def cursor(self):
from django.conf import settings
cursor = self._cursor(settings)
-if settings.DEBUG:
+if settings.DEBUG or self.playback_only:
return self.make_debug_cursor(cursor)
return cursor
def make_debug_cursor(self, cursor):
from django.db.backends import util
-return util.CursorDebugWrapper(cursor, self)
+return util.CursorDebugWrapper(cursor, self,
playback_only=self.playback_only)
class BaseDatabaseOperations(object):
"""
--- django_orig/django/db/backends/util.py 2007-08-19
21:22:44.0 -0400
+++ django_live/django/db/backends/util.py 2007-08-19
21:31:12.0 -0400
@@ -9,14 +9,16 @@ except ImportError:
from django.utils import _decimal as decimal# for Python 2.3
class CursorDebugWrapper(object):
-def __init__(self, cursor, db):
+def __init__(self, cursor, db, playback_only=False):
self.cursor = cursor
self.db = db
+self.allow_execute = not playback_only
def execute(self, sql, params=()):
start = time()
try:
-return self.cursor.execute(sql, params)
+if self.allow_execute:
+return self.cursor.execute(sql, params)
finally:
stop = time()
self.db.queries.append({
@@ -27,7 +29,8 @@ class CursorDebugWrapper(object):
def executemany(self, sql, param_list):
start = time()
try:
-
Re: GSoC Update: [Check Constraints] Django Developers stump me, Final Update as GSoC Project
> To be fair (to us), this > threadhttp://groups.google.com/group/django-developers/browse_frm/thread/4f...was > all about exactly that. It mentioned management.py in the title, so that > counts as a clear warning in Open Source mailing list terms (sometimes > threads veer wildly off course from their titles). Woops...looks like I overlooked the threadso a warning was given and I missed it. Cheers Thejaswi Puthraya --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: GSoC 2007 Status Update VII: Django REST interface
2007/8/19, Andreas Stuhlmüller <[EMAIL PROTECTED]>:
>
> On 8/17/07, David Larlet <[EMAIL PROTECTED]> wrote:
> > Just one (latest?) thought, it's a bit hard to debug because
> > 400 errors are not really verbose, is it possible to find a
> > way to make debug easier? For the moment, I have: if
> > settings.DEBUG: print i.errors but I'm sure it can be better.
>
> I made the 400 error template a bit more verbose. The responder
> classes that use serializers include the model errors in their
> responses anyway. Is this what you were looking for?
Exactly, thanks for your pointer.
>
> > In fact, the problem is that you use ResourceForm in
> > model_resource and it could be interesting to use the given
> > form_class instead.
>
> You're right, it might be nice to be able to change the validation and
> data cleanup behavior of resources. Check out the latest revision and
> tell me if this is along the lines you were thinking.
>
That's what I had in mind, thanks for your reactivity.
Two little "issues" (maybe issues should be submitted to the google project?):
* in TemplateResponder.update_form(), the 'update' var allow to deal
with different forms in the same template (add the hidden fake PUT
field for instance) but given the fact that there is no 'update' var
in the create_form() function, you can't simply use {% if update %},
simple patch: add 'update': False.
* in update_form(), you test if request.PUT: but AFAIK with the
middleware you can't do that, you should test with if request.method
== 'PUT':
David
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: #5188 and backwards-incompatible change (remove order_by from date-based generic views)
On Aug 17, 12:00 pm, Gary Wilson <[EMAIL PROTECTED]> wrote: > Yes, I do not like the idea of adding a new order_by parameter > either. However, there is a bit of an issue involving the > archive_index view though because it also uses a num_latest parameter, > IMHO implying that the items will be sorted by date_field descending. Hm. Since archive_index is explicitly meant to provide the latest objects, I could see keeping the order_by in that view, and making it clear in the docs that it'll override any ordering you try to do on the QuerySet before having to the view. But archive_year should drop its explicit ordering for consistency with the other generic views. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: GSoC Update: [Check Constraints] Django Developers stump me, Final Update as GSoC Project
On Sun, 2007-08-19 at 15:25 +, Thejaswi Puthraya wrote: > Hello Django Developers, > > On August 20th ie tomorrow, Google Summer of Code 2007 will officially > close and all students are required to commit the code written over > the past two odd months. As I was preparing to commit my code I was > stumped to see that my project's code broke post revision 5923. > > The reason was that the manage.py file has now been diversified (check > changeset 5923 and 5925). This happened too close to the project's > final deadline and this gave me a few anxious moments. I thought I had > to literally start from scratch because I was patching the > management.py. On closely studying the new pattern of the management I > realized that all the functions had been neatly divided. This is a > welcome sign but there was hardly any prior communication of such a > shakeup...a small warning atleast on the devel list would have helped. To be fair (to us), this thread http://groups.google.com/group/django-developers/browse_frm/thread/4f94a805f73072da was all about exactly that. It mentioned management.py in the title, so that counts as a clear warning in Open Source mailing list terms (sometimes threads veer wildly off course from their titles). > By the way, I have to congratulate the developers for finally > diversifying code and making the code more organized. > > Now regarding my project's goals. I have completed all except two > goals one being implementing the "upper" and "lower" methods on check > fields and the second, integrating django-check-constraints with the > Django Admin. The reason for not implementing the "upper" and "lower" > methods currently is that they are not fully "unicode"-compatible in > Sqlite (because they use C's tolower and toupper routine). The current > way of integrating django-check-constraints with admin would be by > using manipulators (which is not recommended because newforms is going > to be the de-facto standard from the next release). So I will > integrate with the admin as soon as newforms-admin is merged into the > trunk. (When I talk of integrating with django-adminI mean > displaying neat errors.) Well done. Getting that close to your original goals is excellent work. Regards, Malcolm -- The sooner you fall behind, the more time you'll have to catch up. http://www.pointy-stick.com/blog/ --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
GSoC Update: [Check Constraints] Django Developers stump me, Final Update as GSoC Project
Hello Django Developers, On August 20th ie tomorrow, Google Summer of Code 2007 will officially close and all students are required to commit the code written over the past two odd months. As I was preparing to commit my code I was stumped to see that my project's code broke post revision 5923. The reason was that the manage.py file has now been diversified (check changeset 5923 and 5925). This happened too close to the project's final deadline and this gave me a few anxious moments. I thought I had to literally start from scratch because I was patching the management.py. On closely studying the new pattern of the management I realized that all the functions had been neatly divided. This is a welcome sign but there was hardly any prior communication of such a shakeup...a small warning atleast on the devel list would have helped. By the way, I have to congratulate the developers for finally diversifying code and making the code more organized. Now regarding my project's goals. I have completed all except two goals one being implementing the "upper" and "lower" methods on check fields and the second, integrating django-check-constraints with the Django Admin. The reason for not implementing the "upper" and "lower" methods currently is that they are not fully "unicode"-compatible in Sqlite (because they use C's tolower and toupper routine). The current way of integrating django-check-constraints with admin would be by using manipulators (which is not recommended because newforms is going to be the de-facto standard from the next release). So I will integrate with the admin as soon as newforms-admin is merged into the trunk. (When I talk of integrating with django-adminI mean displaying neat errors.) I have tested the project extensively writing around 50 doc tests and testing with various cases and databases. The databases used for my test were: Postgresql 8.2.4 Sqlite 3.3.13 Oracle 10g Haven't checked for other versions but should work for all versions that support and enforce check constraints. I had written two blog entries showing how to use django-check- constraints. http://thejuhyd.blogspot.com/2007/07/django-newforms-and-django-check.html http://thejuhyd.blogspot.com/2007/08/django-newforms-and-django-check.html Hope they give an indicator. I would also like to thank all Django developers especially Jacob, Adrian and Malcolm for all the support. A special "thanks" to my mentor Simon Blanchard for guiding me through this project even through his busy schedule and for keeping up with all tantrums that I threw at him ;-) I would also like to thank Kenneth Gonsalves for having given me this idea at the start of Summer of Code. Hope you use and love Django-Check-Constraints http://code.google.com/p/django-check-constraints PS: Don't mistake this for my last mailI hope to contribute lot more to Django...and would like to sign off by screaming "DJANGO ROCKS!!!" (so does POSTGRESQL) ;-) Cheers Thejaswi Puthraya --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: GSoC 2007 Status Update VII: Django REST interface
On 8/17/07, David Larlet <[EMAIL PROTECTED]> wrote: > Just one (latest?) thought, it's a bit hard to debug because > 400 errors are not really verbose, is it possible to find a > way to make debug easier? For the moment, I have: if > settings.DEBUG: print i.errors but I'm sure it can be better. I made the 400 error template a bit more verbose. The responder classes that use serializers include the model errors in their responses anyway. Is this what you were looking for? > In fact, the problem is that you use ResourceForm in > model_resource and it could be interesting to use the given > form_class instead. You're right, it might be nice to be able to change the validation and data cleanup behavior of resources. Check out the latest revision and tell me if this is along the lines you were thinking. Regards, Andreas --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Unhandled exception if object with existing unique key saved
On Sun, 2007-08-19 at 05:19 -0700, ludvig.ericson wrote: > Well actually, I see implementation leakage in the API here. > > Does it make sense that the Django ORM raises SQLite3 exceptions? I > wouldn't want _to try to try to_ catch either of all integrity > exceptions. > > Perhaps something like 'django.db.IntegrityError' or so. We already have that. You can catch django.db.IntegrityError and it will work (same goes for DatabaseError). The exception class still reports its own name as sqlite3.IntegrityError or whatever it is, but that's just an unavoidable Python feature (a consequence of using references). Regards, Malcolm -- On the other hand, you have different fingers. http://www.pointy-stick.com/blog/ --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Unhandled exception if object with existing unique key saved
Well actually, I see implementation leakage in the API here. Does it make sense that the Django ORM raises SQLite3 exceptions? I wouldn't want _to try to try to_ catch either of all integrity exceptions. Perhaps something like 'django.db.IntegrityError' or so. Ludvig Ericson --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
