Is there a way the DatabaseFeatures would supply different values for
different versions of configured SQL server?
Thanks, Peter
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to
I notices that refactored OneToOneField creates artificial primary key
as UNIQUE, whereas all other primary keys generated by Django omits
such declaration, because it is inherent (at least on MySQL)
Setting kwargs['unique'] = False in OneToOneField constructor
supresses this, but I don know if
> Look at the constructor of django.db.models.sql.query.Query for the
> "connection" argument.
You know, I grepped on that but didn't see anything interesting. Now
with a two-beer-handicap, I'll go with Blanche DuBois -- Tomorrow is
another day.
On Fri, May 9, 2008 at 9:27 PM, Peter Rowell <[EMAIL PROTECTED]> wrote:
> OK, I'll bite. I kind of doubt he rewrote the templating system in the
> ORM, so you must be inferring that multiple database support was part
> of the qs-refactoring. I just checked out trunk and I'll admit I'm
> working
> You probably should take a look at the ORM code.
OK, I'll bite. I kind of doubt he rewrote the templating system in the
ORM, so you must be inferring that multiple database support was part
of the qs-refactoring. I just checked out trunk and I'll admit I'm
working with a one-beer-handicap at
On Fri, May 9, 2008 at 9:01 PM, Peter Rowell <[EMAIL PROTECTED]> wrote:
> Now that Malcolm has subclassable models working, my number one
> complaint is the templating system. Number two is single DB, but I can
> work around that more easily.
You probably should take a look at the ORM code.
--
> QuerySets are lazy [...] What are you trying to accomplish that is any
> different?
I'm working around the fact that Django's templates can't take
arguments. So I'm calling formatting functions which *do* take
arguments, one of which is a QuerySet. Of course, I can't pass args to
a function
On Fri, May 9, 2008 at 8:12 PM, Peter Rowell <[EMAIL PROTECTED]> wrote:
>
[snip]
> In order to delay a *very* expensive DB operation, I decided to put it
> in a function and pass the function as a context variable. The
> template uses fragment caching with vary_on, so only if the template
>
On Saturday 10 May 2008 03:23:39 Peter Rowell wrote:
> BTW, I tried to add a comment on this to
> http://code.djangoproject.com/ticket/7153, but got "Internal Server Error
> (Submission rejected as potential
> spam)", which struck me as rather rude. :-)
>
I was just gonna point you to #7153.
I
BTW, I tried to add a comment on this to
http://code.djangoproject.com/ticket/7153,
but got "Internal Server Error (Submission rejected as potential
spam)", which struck me as rather rude. :-)
--~--~-~--~~~---~--~~
You received this message because you are
Short version:
Callable context variables do not get called during resolution. If
invoked as a simple variable they return something like . If used in a for loop, they blow up the template. I'm
running trunk:7374
Longer version:
In order to delay a *very* expensive DB operation, I decided to
The problem is that the parent object is saved, and then child object is
saved. When the child model is saved it attempts to create the parent object
again. It then fails constraints.
After playing around with it a bit, it makes sense that the fix shouldn't be
in the model.save().
However, it
Here is one of my current real-world, common, examples:
Monthly maintenance costs - Report
custom_sql_query = """
SELECT c.id, p.short_title, sum(f.amount)
FROM manager_contract c, manager_financialtransaction f,
manager_property p
WHERE f.pub_date >= '%s' and
So I have setup Django on IIS using PyISAPIe and am happy with the
performance so far. On my dev box running IIS 5.1, I am getting ~170
requests per second processed for the simple poll application.
Django is running as a WSGI application. I have reconfigured the
PyISAPIe files to look for a
On Fri, May 9, 2008 at 3:58 PM, Alen Ribic <[EMAIL PROTECTED]> wrote:
>
> Reporting is quite common in my area of work at the moment and most of
> the time some form of aggregation is required to build meaningful
> reports. (For such case I have substantially more custom/native
> queries then
Reporting is quite common in my area of work at the moment and most of
the time some form of aggregation is required to build meaningful
reports. (For such case I have substantially more custom/native
queries then standard ones.)
-Alen
(PS. if there is a need to give some real example with
RSpence
Life is for living
Knowledge is the key to success!
http://www.forex-killer.com/?hop=rspence1
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to
17 matches
Mail list logo
