t;>
>> On April 18, 2015 3:35:09 AM GMT+02:00, Marcin Nowak <
>> marcin@gmail.com> wrote:
>> >Hi.
>> >Just give people possibility to disable migrations functionality
>> >(remove it
>> >from core and put as a contrib app, if needed
I agree that perhaps making it part of signals is not in everyone's favour
(as signals are kind of unloved) but I also like the simplicity of
Christopher's approach - the patch is small and understandable, and using
it is pretty easy (especially to upgrade existing code into "safe" code).
Unless i
Hi Tom,
When you say "testing migrations", what do you mean exactly? The migration
framework itself is heavily unit-tested, so I presume you intend to test
things like custom RunPython function bodies and the like?
Andrew
On Thu, May 7, 2015 at 3:30 AM, Tom Linford wrote:
> At Robinhood, we've
I agree with Markus/Tim - the whole point of faked migrations is that
they're meant to exactly match the existing schema. If Django is
auto-faking migrations that don't match the existing one that would be a
bug, but it's almost too conservative in that aspect.
Are you manually faking these migrat
would have a record
> for every migration executed (including backwards).
>
> Shai.
>
> On Wednesday 13 May 2015 20:34:19 Andrew Godwin wrote:
> > I agree with Markus/Tim - the whole point of faked migrations is that
> > they're meant to exactly match the existing schema
Just to chime in here - I've long been in favour of some kind of support
for event-driven stuff inside Django, but as Curtis is saying, there's
nothing here that couldn't be done in a third party app first and then
proven there before any possible merge into core.
I also don't think that this prop
OK, so I've just gone ahead and done the initial work on this:
https://github.com/django/django/pull/4729
I'd appreciate testing by people to see how well that new sql command
works; it's fine for me in dev here against a simple project but there's
probably some edge cases. Nevertheless, it seems
to push through changes.
Andrew
On Mon, Jun 1, 2015 at 11:11 PM, Emil Stenström wrote:
> Thanks for you reply Andrew,
>
> On Monday, 1 June 2015 13:05:34 UTC+2, Andrew Godwin wrote:
>>
>> Just to chime in here - I've long been in favour of some kind of support
>
I agree with Loïc that this problem is probably best solved when the
virtual/composite stuff is finally sorted out; I don't want us to put in a
quicker fix that's not going to match those, and that's already going to
have to deal with things like composite keys and potentially changing FKs
anyway.
Hello everyone,
I've been formulating a plan to decouple Django from the request-response
cycle for a couple of years now and after discussing it with some people at
DjangoCon Europe I thought it was high time that I actually wrote it up,
wrote some code, and solicited feedback.
So here it is. Th
ango as a tool
> instead of a coding style, I think Redis/NoSql/Database backend/ is good
> enough as a first step.
>
> On 15 June 2015 at 03:25, Andrew Godwin wrote:
>
>> Hello everyone,
>>
>> I've been formulating a plan to decouple Django from the request-r
:
>
>> Sorry, I haven't read the source code. But I basically read the doc. Thus
>> in a multithreaded env, we will use Redis or something to implement the one
>> to one chat function, am I right?
>>
>> Thus people might be confused with the different channels
Hi Marcin,
Django will only make migrations for external apps that already have
"migrations" directories and have model changes - it shouldn't make new
migrations unless you've actually changed the models in those reuseable
apps. Are you sure you're not specifying the names of those apps on the
ma
es attribute even
> if database schema is not really altered?
> And the original question modified - should Django generate migration file
> inside of an egg when runtime configuration or settings are changing?
>
> BR,
> Marcin
>
>
>
> On Thursday, July 16, 2015 at 12:07:52 AM
ided as a resource(s) to pick/import.
>
> I would like to spent some time while creating stable and solid migrations
> in my project instead of searching workarounds for runtime issues.
> But this means a big architecture change and I know that is improssible to
> do for years...
uot; settings to
> their values and instead include that as references in auto-generated
> migrations is something we should try to implement?
>
> If so, let's suggest that solution on
> https://code.djangoproject.com/ticket/24648
>
> On Wednesday, July 15, 2015 at 7:58:02 PM
MIGRATION_MANAGED_APPS to None (default) should enable backward
> compatibility.
>
>
> On 17 July 2015 at 12:42, Shai Berger wrote:
>
>> On Thursday 16 July 2015 02:10:12 Andrew Godwin wrote:
>> >
>> > Also, yes, Django doesn't see unpacked .egg files as any d
On Fri, Jul 17, 2015 at 11:19 AM, James Bennett
wrote:
> One option for declaring an app "unmanaged" could be via AppConfig. That's
> fairly clean, mirrors the way you can already set a model as unmanaged in
> its Meta declaration, and allows for the end user of the app to override by
> supplying
My main problem with "defaults in the database" was that the current
"default" kwarg is too expressive for things we can put into a database and
doesn't allow representation of "NOW()", etc. I'd be happy with a
default_db arg with defined semantics and that would just blow up if you
tried to pass a
And I'm not even talking about the
>> migration optimizer which probably needs to get a lot smarter if we take
>> this road.
>>
>> syncdb, which leaves a developer with a database scheme that cannot be
>> altered automatically, is something we should get rid of as
The main problem I forsee here is just making sure that the MigrationLoader
knows to take these located-in-the-wrong-place migrations and insert them
into the migration tree right - in particular, you have issues with the
dependencies, because say you made a third-party migration that depends on
ap
On Mon, Aug 24, 2015 at 10:19 PM, Emmanuelle Delescolle <
delesco...@gmail.com> wrote:
> I've been using this solution on a couple projects (including ones with
> several children to the same migration) and have never had troubles with
> the migration solver, I guess I have been lucky.
>
> I'll th
eful info
>>> if self.verbosity >= 1:
>>>
>>> On Thursday, August 6, 2015 at 9:50:10 PM UTC-4, Markus Holtermann wrote:
>>>>
>>>> Instead of rushing to a decision if and of how we continue to support
>>>> "apps w/o migrat
Hi Gavin,
Hooking into the migration autodetector is currently not really possible -
it's quite inextensible, which is something I'd love to get ironed out in
the long term but isn't really possible right now to modify it from
third-party code.
You can, however, supply custom migration Operation
t; constraint.
>
> Do you think it's possible for anyone besides you to work on making the
> migration framework more extensible? I'm interested in contributing in this
> area.
>
>
> On Thursday, August 27, 2015 at 8:07:55 PM UTC-6, Andrew Godwin wrote:
>>
>> Hi G
On Thu, Aug 27, 2015 at 10:25 PM, Anssi Kääriäinen
wrote:
> Could we allow applications to have fake migration files? I'm thinking
> of something like operations.AllModelsUpdated(). After this operation
> is ran, Django will use the present models for that app. You could
> place this as your last
>
>
> Not to take away from the value of working on making
> migration-extensions more accessible to third-party code (I think that
> would be great), but have you considered just doing this work in core? I
> would guess there'd be strong support from the core team for having a
> check-constraints
I'm on board merging this without Oracle support - if I understand right,
it means we just have to run those non-parallel for now, so we're not
losing anything, right?
Andrew
On Sun, Aug 30, 2015 at 1:19 PM, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:
> Hello,
>
> I polished my
I still feel like merge migrations are necessary, if not only because
they're a way of reducing the potential collision area of migration
ordering from different branches, but it might be that the solver is
predictable enough that it's not a problem. Two separate branches in
migrations still don't
Hi Christian,
Squashmigrations contains just the sort of optimiser you mention, complete
with all the examples you mention (though because it's foreign-key-aware,
it sometimes can't optimise everything away, as it can only see a single
app).
It's not used at execution time, however, as part of th
I think if the fix is easy, we should continue to support them past 1.7,
since we're retaining syncdb support. However, if it's crazy complicated,
it's likely not worth it.
Andrew
On Wed, Nov 4, 2015 at 11:59 PM, David Filipovic
wrote:
> I have initially created the ticket
> https://code.django
other
> way for
> the user to tell us that syncdb is ok for this app, but IMO that takes us a
> step beyond Andrew's "fix is easy".
>
> Shai.
>
>
> On Saturday 07 November 2015 12:13:02 Andrew Godwin wrote:
> > I think if the fix is easy, we should c
Yes, as Tim says, 1.9 actually introduces the ability to mark apps as not
having migrations; we specifically chose to keep supporting the
migration-less creation format, just as an explicit setting.
Note that you can't give an app migrations normally but run the tests
without them; for correctness
I also agree this looks sensible - I think South even had an attribute like
this on the migration class, it just never got ported over. +1
On Tue, Nov 24, 2015 at 8:19 AM, Marc Tamlyn wrote:
> +1 to idea and API. I've wished I had this recently - even if it's just so
> I can check up on the prog
You can undo a migration manually using migrate, though if you're in
multiple-tip-migration scenario you may need to make a merge migration
first (but not apply it) or switch to a branch with only the migration you
wish to undo.
The more general rebase command would be interesting, though I've alw
e the twin-tip check on the migrate command if you're asking to reverse
one of those tips; that should solve that issue.
Andrew
On Wed, Dec 2, 2015 at 2:48 PM, Shai Berger wrote:
> On Tuesday 01 December 2015 08:40:34 Andrew Godwin wrote:
> > You can undo a migration manually using
Hi everyone,
For those who haven't seen, Mozilla has awarded $150,000 to Django for work
on Channels and request/response improvements lifted from REST Framework.
More in the blog post here:
https://www.djangoproject.com/weblog/2015/dec/11/django-awarded-moss-grant/
I'll be coordinating this effo
Channels is indeed a replacement for Celery if you're OK with not having
delays, retry, or the other advanced options Celery has - Channels just
requires an event to respond to, and this can be triggered by the user
during a view much like a Celery task.
But yes, channels deliberately has an at-mo
On Wed, Dec 16, 2015 at 9:52 AM, Markus Holtermann wrote:
>
> >If I get it right -- Curtis' description is spot-on; some tasks will
> >still
> >need Celery, Channels will take care of many others.
>
> For me it's more a question of "is a client directly involved".
>
I don't agree; I think it's m
omething like Pulsar to power our "async django".
> Is there anything to be gained from using a more actor driven concurrency
> model or adopting any of the other methods used in their 'pulse' django app?
> I suppose I'm just trying to work out how to compare usin
Hi everyone,
One of the first steps I want to get done for Channels is get a rough plan
in place for how things are going to work in terms of where code goes,
supported versions, etc. I've written up my thoughts on this into a first
draft of what I'm calling the "integration plan":
http://channel
To address the points so far:
- I'm not yet sure whether "traditional" WSGI mode would actually run
through the in memory backend or just be plugged in directly to the
existing code path; it really depends on how much code would need to be
moved around in either case. I'm pretty keen on keeping a
wrote:
> On 12/17/2015 11:50 AM, Andrew Godwin wrote:
> > - I thought SCRIPT_NAME was basically unused by anyone these days, but
> > hey, happy to be proved wrong. Do we have any usage numbers on it to
> > know if we'd need it for a new standalone server to implemen
these would then push the HTTP
> requests through channels to worker processes, which process the message
> and push the response through the channel backend back to the interface
> server and from there back to the client?
>
> - Anssi
>
> On Thursday, December 17, 2015, Andre
e
> with a more_content attribute.
>
> Sam
>
> On Thursday, December 17, 2015 at 9:48:31 PM UTC, Andrew Godwin wrote:
>>
>> Yes, that is the idea. While it obviously adds overhead (a millisecond or
>> two in my first tests), it also adds natural load balancing
sts.
I think Django absolutely has to adapt to the modern web environment and
move away from just rendering templates when browsers request them, and
this to me is part of that. If there are other solutions to the same
problems I think we should consider them as well; I've just not run across
any
eople will want to turn on, and that provides a lot of value
in exchange for a slight round-trip performance hit - my goal is sub-5ms,
and preferably sub-3. If it starts being 10/20/30 milliseconds of cost,
then we'll have to change our approach until it's acceptable.
If you don't want
and civility in these discussions. I
> know
> this is something you've been working hard on and I'm not trying to be
> needlessly critical of your work.
>
I honestly appreciate your feedback here too - it's very hard to see these
things from the outside, so it's im
On Fri, Dec 18, 2015 at 5:28 PM, Anssi Kääriäinen
wrote:
> On Friday, December 18, 2015, Andrew Godwin wrote:
>
>>
>>
>> On Fri, Dec 18, 2015 at 3:44 PM, Mark Lavin wrote:
>>
>>> > You seem to be assuming I'm here to foist a brand new middle layer
ven channel in both the redis and database backends, which is a good
rough metric, though in systems like this I do prefer to know queue time
(i.e. how long are items on the queue before consumption) - that's a lot
harder though.
Might be a good idea to carve out a channel_length() API on backe
case of keeping a major
addition like this as simple and backwards-compatible as possible.
Rewriting everything from scratch would be lovely, but unfortunately part
of maintaining a framework is not doing that.
Part of me, though, would be very interested in such a project being
undertaken to see ho
documentation and so forth. Any radical change that
might end up happening would have to happen in slow steps over many
releases, and only with the buy-in of the community - I don't even fully
have that yet, and I don't expect to get it until Channels can show that it
works, is backwards-compa
On 01/10/10 11:17, Luke Plant wrote:
Passing things around between '_common' and GET and POST makes a simple
view much more complex than it needs to be, especially when you have
various local variables that you now have to assign in some way. In the
end you will end up just routing it all to the
On 01/10/10 16:25, Brandon Konkle wrote:
On Oct 1, 2010, at 10:20 AM, Alex Gaynor wrote:
Not really. The big win from a class-based view is not being able to
store state, you can do that with local variables, it's being able to
override parts of the behavior without needing to rewrite the
On 03/10/10 03:20, Russell Keith-Magee wrote:
* Ignore the legitimate occasions where using state is a useful
architectural approach.
I'd just like to add more noise to the signal and reiterate this -
storing state on self (or request) leads to much cleaner, less fragile,
more subclassa
On 04/10/10 17:28, legutierr wrote:
* First, treat data processing and retrieval as separable from
rendering. Create a bright line of separation between the two
conceptual elements of the view (data and rendering), and do it early
on, at a high level, inside dispatch(). Instead of expecting
On 11/10/10 07:05, Alex Gaynor wrote:
I think the solution there is something like:
@skipUnless(sys.version>= (2, 5))
def test(self):
exec """
from __future__ import with_statement
with self.assertNumQueries(1):
Model.objects.get(pk=2)
"""
Not exactly beau
On 15/10/10 13:41, J. Pablo Martín Cobos wrote:
Hi,
I'm a Django developer since more or less 3 years. Some time ago I had
the need for the extends templatetag to have more funcionality.
The funcionality I mean is that a template can extends from "itself".
I'm going to try to explain it bett
On 15/10/10 14:52, Ian Lewis wrote:
On Fri, Oct 15, 2010 at 2:06 PM, Russell Keith-Magee
mailto:russ...@keith-magee.com>> wrote:
However, this isn't a decision we need to make right now. If we land
what we have, we can fiddle with it until the RC comes out; if we are
getting to tha
On 20/10/10 02:40, Stephen Kelly wrote:
Sorry. Sent too early. All thumbs today. Consider these examples:
{% verbatim "%} %}" %}
(That is, "%} %}" in a verbatim-no-end tag)
{% verbatim %} %} %} {% endverbatim %}
(That is, " %} %} " wrapped in verbatim tags)
The current lexer uses regexps to
On 23/10/10 12:54, George Sakkis wrote:
This has been (rightly) marked as DDN, so I'm wondering if there are
any thoughts on it to move it forward, one way or another. Original
thread at
http://groups.google.com/group/django-developers/browse_frm/thread/3b5939ba089bce51/67892d99a9a6aff3.
Georg
On 23/10/10 14:28, Luke Plant wrote:
You can do it if you do something like this in your views.py:
my_view = MyView.as_view()
That way you export your view as both a function to be used as a view
directly, and a class for further re-use. If your CBV cannot be used
directly (e.g. needs to b
On 27/10/10 07:01, Simon Meers wrote:
Has anyone else found that using prepopulated_fields in
admin.ModelAdmin since r14123 produces a javascript error: "d.join is
not a function"?
I didn't get any errors when I tested the patch before commit - are you
having them on the 1.2.X backport, or th
On 27/10/10 12:15, Simon Meers wrote:
> On 27 October 2010 19:40, Andrew Godwin <mailto:and...@aeracode.org>> wrote:
>
> On 27/10/10 07:01, Simon Meers wrote:
>
> Has anyone else found that using prepopulated_fields in
> admin.ModelAdmin since r
So, I've been trying to trace a bug that's been affecting me as well as
someone else I know, to do with ModelForms / the admin and CharFields
with null=True, blank=True, and unique=True
The old ticket for this was closed as WONTFIX:
http://code.djangoproject.com/ticket/9590
However, I'd personall
On 11/11/10 01:40, Karen Tracey wrote:
>
> There is a way, it just requires some admin customization. See:
>
> http://stackoverflow.com/questions/454436/unique-fields-that-allow-nulls-in-django/1400046#1400046
Right, and you can also register a pre_save hook to fix this, but it's
just ugly.
>
> I
On 13/11/10 16:52, Daniel Moisset wrote:
Hi,
while working on the sprint today doing triaging we noticed that a
lot of tickets were in the "Unreviewed" state because actually there's
not enough information to move it to any other state (they can not be
neither accepted/DDNd nor closed). In mo
On 15/11/10 01:35, Russell Keith-Magee wrote:
On Sun, Nov 14, 2010 at 5:22 PM, Andrew Godwin wrote:
On 13/11/10 16:52, Daniel Moisset wrote:
Hi,
while working on the sprint today doing triaging we noticed that a
lot of tickets were in the "Unreviewed" state becaus
On 21/11/10 02:52, Carl Meyer wrote:
> Hi all,
>
> The special-cased handling of contrib.admin static assets in Django
> core is a long-time wart. Fortunately, the new static assets standard
> introduced by contrib.staticfiles and the STATIC_URL and STATIC_ROOT
> settings finally allows us to begin
So, one of the complaints I've heard from a few people now is the fact
that 404 is the only thing one can raise as a HTTP error - there are
plenty of others, such as 403 and 405, that could be useful to raise
back to the client.
This didn't used to be much of a problem with function-based views -
On 03/12/10 22:50, Russell Keith-Magee wrote:
This proposal has come up before and has historically been rejected;
however, your point about class-based views makes it a lot harder to
give the standard responses.
Yup; this email came directly from using the new CBVs and hitting this
very probl
On 04/12/10 09:15, Tim Diggins wrote:
View& template:
look for a handle{{status_code}} variable, falling back to
handle_exception. The generic handle_exception in non-DEBUG looks for
a specific "{{status_code}}.html" template, but falls back to a (say)
"http_exception.html" template. (there woul
My personal preference is for (4). I don't like the addition of a
setting, but it's a setting that most users will be able to ignore
(since there is a reasonably sensible default), and it is the most
explicit and configurable option available.
My opinion with the current codebase is for (4), b
On 07/12/10 23:26, schinckel wrote:
I haven't been able to find any documentation about this, but would be
happy to be pointed in the right direction.
When you use null=True in a field, and then use that model in the
admin, it will not save NULL to the database, but will instead save an
empty st
So, I've been working with the new generic Class Based Views for the
last few days, and come across a slight inconsistency in the ListView.
If you specify a value for paginate_by, ListView happily returns a
"page" object into the context. However, if there is only one page, it
decides against this
On 12/01/11 17:54, Daniel Swarbrick wrote:
> Most of the time, I use POST for forms, but using GET is useful when
> developing a search form, for example. This is especially true if you
> want to paginate your results, because you still have all your
> original form variables in the query string.
>
On 14/03/11 21:14, Michal Petrucha wrote:
Good evening (or whatever it is in everyone's timezone).
I'm an undergrad computer science student at the Faculty of
Mathematics, Physics and Informatics, Commenius University,
Bratislava, Slovakia and I'm willing to participate in this year's
GSoc. I'm
Hello everyone,
Django has once again been accepted as one of the participating projects
for Google Summer of Code, and so we're now looking for student projects!
I've taken over the role of GSoC administrator from Jannis this year;
feel free to email me directly (or catch me on IRC) if you have
a
On 17/03/11 07:47, Vivek Narayanan wrote:
> Hi,
>
> This is my proposal for the customizable serialization idea:
Hi Vivek - sorry about the long reply-wait on this! My initial thoughts
are below.
> The user can define methods beginning with “meta_” to add metadata
> about each field. And function
Hi everyone,
Just a reminder that student and mentor applications for GSoC are now
open on the SoC website (middle column, at the bottom):
http://www.google-melange.com/gsoc/homepage/google/gsoc2011
Students, you have until 7pm GMT on April 8th to get your submissions
in; if you want more inform
On 30/03/11 12:58, Rohit wrote:
> Hi,
> I plan to implement HBase backend support for Django as part of
> GSoC 2011. Before I flesh out the idea in detail, I would like to know
> if this is useful enough to Django, whether there are alternatives to
> using HBase in the first place.
Hi Rohit,
As the subject suggests, any potential students who would like to apply
to Django for this year's Google Summer Of Code have just over two days
left to prepare your proposals and get them submitted.
Remember, we'll look much more kindly on proposals that have been
submitted to django-developers fo
Hello potential GSoC students,
There's now less than 24 hours before the deadline closes for GSoC - it
closes at 19:00 UTC on April 8th (that's around 20 hours from when this
post was sent).
If you've got a proposal that isn't in google-melange yet, please
register and add it; you're allowed to u
Hi everyone,
I'm pleased to announce our four accepted GSoC projects for this year:
Template Engine Compilation and Runtime Refactoring
---
Student: Armin Ronacher
Details:
http://www.google-melange.com/gsoc/project/google/gsoc2011/mitsuhiko/10001
ab wrote:
> For the api to accept a DSN, alias, or connection anywhere would add
> similar code in multiple places. I propose that the aliases are mapped
> into django.db.connections. For your example, you could use
> django.db.connections.archive. I also propose that you can either
> define a sin
So, hello everyone. I figure this list is the best place to ask this,
but please feel free to deride me if not...
After all the talk of multiple databases, and non-relational databases
(bigtable, couchdb, etc.) that went on at DjangoCon and afterward,I've
been thinking about denormali[s/z]ation a
David Cramer wrote:
> If you're not doing denormalization in your database, most likely
> you're doing something wrong. I really like the approach that is
> offered here.
>
> For me, personally, it would be great if this could accept callables
> as well. So you could store the username, like so, o
Yes, Steve, it's true that triggers do have much of the same
functionality as this kind of proposal, but as you say, part of the
proposal is to make these hopefully work with future non-SQL databases
(although, admittedly, that's only a small piece of the puzzle).
To be honest, my main drive i
David Cramer wrote:
> I would say ignore triggers on the DB level, until they've been
> written in the framework.
>
Yes, this was essentially my point earlier; triggers would be nice to
have from a consistency point of view, but it will be easier and quicker
to reimplement them in Python, not
So, after the general, soft consensus of
http://groups.google.com/group/django-developers/browse_thread/thread/9a672d5bbbe67562/248e53722acab49e,
I've put my money (or should that be time?) where my mouth is and
actually coded my suggested solution.
The current diff against trunk is attached - the
Russell Keith-Magee wrote:
> I do have a slight reservation regarding the API you are proposing.
> The fields you have proposed (MirrorField and AggregateField) capture
> the obvious use cases, but the syntax don't feel consistent with the
> rest of the Django API. In particular, AggregateField se
A Mele wrote:
> I have followed the discussions about denormalization and I really
> would like to see this in trunk. I agree with Rusell, the syntax
> should be more like Django's query syntax, but I think this kind of
> field is very useful for a lot of projects.
>
I obviously agree, but Rus
David Cramer wrote:
> I'm not sure on AggreateField either. What if you just do like
> ("Photo", "user__exact=self.user") or something. Currently there's no
> rerepsentation for "self" in Django QuerySet's, so this is a hard
> thing to call. Also, we need a way to support callables.
>
> e.g. model
Hmm, now that's an interesting implementation. I'm pleased to see you've
essentially taken the same route I did in terms of detecting when to
save, which means I'm not being as silly as I first thought.
The decorator syntax is nice, and certainly something that should be
around - however, I (natu
Christian Schilling wrote:
> i don't think so.
> if you mean lines 35-38 in fields.py:
> this is only used to rebuild all denormalized values in the whole DB
> via the management command, witch means everything needs to be updated.
>
Ah yes, ignore me. I was trying to see how you did 'efficien
So, I've had a good look over the (constantly-growing!) code here, and
I'm really beginning to like the decorator approach, especially the nice
way you combine dependencies with the dependency classes, which makes my
solution to old/new FK values look terrible.
I still have two issues, although I
Christian Schilling wrote:
> I think the problem here is that you need to alter a model after
> django has initialized it, because there is just no other way to auto-
> detect
> the field-type of the mirrored field. So eliminating the need to type
> both the related model name as well as the field
Christian Schilling wrote:
> yes, i merged that, ran my old tests against the fixed version and
> found a bug in the fix..
> so, i recreated the scenario in the new testsuite and fixed the
> fix ;-)
>
Ah, the wonderful meta-loop of fix fixes.
> i think we should really setup a trac instance s
Russ has made some good points, but I feel a need to chime in anyway!
Brantley Harris wrote:
> The idea is a database migration system that:
> * Is simple.
> * Doesn't make you use sql. This is an orm, we shouldn't have to use sql.
>
As Russ said, there's a need for SQL, and his point
Alex Gaynor wrote:
>
>
> class Order(models.Model):
>...
>n_items = DenormalizedField(signal_from='itemorder',
> qs=self.itemorder_set.count())
>total_price = DenormalizedField(signal_from='itemorder',
> qs=self.itemorder_set.sum('item_price'))
>
>
>
101 - 200 of 475 matches
Mail list logo
