At Mozilla we've used a jinja2 template filter called 'urlparams' for quite
some time. You can see the code in jingo here:
https://github.com/jbalogh/jingo/blob/master/jingo/helpers.py#L116
In Python:
urlparams(reverse('translate', kwargs={'slug': document.slug}),
to_locale=locale)
In Jinja2 temp
I opened bug: http://code.djangoproject.com/ticket/15043
I actually stumbled on this just a few days ago while trying to put a
session_key to user ID mapping into Redis upon login and was stumped
for awhile why it didn't match the session key of my logged in user.
-Rob
On Sun, Jan 9, 2011 at 10:
If I recall correctly, there's another branch on the that project that
was refactoring the autocomplete widgets so that there were
essentially 2 widgets: A widget intended to be used in your own
Django code, and an admin widget that was a subclass for use in the
admin.
To me that would be a nice
On Tue, Apr 27, 2010 at 6:38 PM, Leo wrote:
> Digging deep into Python's innards reveals that this is a somewhat
> esoteric protection in case you're writing out Unix mailbox files. The
> specific issue is here:
> http://docs.python.org/release/2.6.2/library/email.generator.html#email.generator.G
On Fri, Feb 19, 2010 at 8:58 AM, Luke Plant wrote:
> IMO, using 'library agnostic' javascript in the admin will mean we
> just end up implementing our own library, which will end up being an
> ad hoc, informally-specified, bug-ridden, slow implementation of half
> of jQuery/dojo/etc, and even less
I've battled many of these same issues when working on the debug
toolbar... it needs to work the same in any environment it gets loaded
into and, as such, has slightly different requirements put on it. It
is seeming the admin is heading the same direction to some degree.
While certain parts of the
On Tue, Nov 24, 2009 at 3:36 PM, Russell Keith-Magee
wrote:
>
> Time zone handling is definitely something that Django could handle
> better, but simply switching to UTC for certain functions isn't the
> solution.
>
I like the solution proposed on ticket 10587:
http://code.djangoproject.com/ticke
On Wed, Oct 21, 2009 at 6:38 AM, David Chandek-Stark
wrote:
>
> The values_list() query set method is useful for dumping data to CSV,
> etc. However, I find that I often want to use it without specifying
> the field names (to get them all) and yet also include the field names
> as the first row i
On Wed, Oct 21, 2009 at 12:22 PM, mrts wrote:
> A DVCS mm-tree
> --
>
> Quoting
> http://en.wikipedia.org/wiki/Andrew_Morton_(computer_programmer)
>
> "He currently maintains a patchset known as the mm-tree,
> which contains not yet sufficiently tested patches that
> might later be ac
On Sat, Oct 10, 2009 at 6:04 AM, Ned Batchelder wrote:
> My strong feeling is that these two goals will quickly become impossible to
> reconcile. I think the idea of a conference site is a good one (everyone
> will understand the problem domain, lots of interesting avenues to explore,
> it's not
I, too, like the idea of a conference site. It fills a void and
sounds useful for upcoming conferences. I wasn't too crazy about the
blog idea, and was convinced away from the snippets idea. So shall we
call it a conference site and move on? :)
For a nice reference implementation, I'd like to
I'd like to propose the addition of a new tutorial that represents a
complete website, describing everything from start to finish. This
would allow for many more topics to come into play -- things we all
deal with at some point in developing websites using Django. This
would also allow for those
On Mon, Sep 28, 2009 at 6:38 AM, Russell Keith-Magee
wrote:
> By way of greasing the wheels towards trunk: if the outcome of this
> mailing list thread was a wiki page that digested all the ideas,
> concerns and issues into a single page, it will make the final
> approval process much easier. Luk
On Sat, Sep 26, 2009 at 11:33 AM, Simon Willison
wrote:
> I don't think it would involve form widgets being rendered with
> templates simply because of the performance overhead - even with the
> template caching improvements it's still a lot of work just to output
> an input tag. It might involve
On Sat, Sep 26, 2009 at 2:13 AM, Simon Willison wrote:
> Yes - I looked briefly at how much work was involved in doing this and
> it's not insubstantial, which is why I opted for string replacement
> just to demonstrate the API. I'm confident the exact functionality of
> django-html could be repl
Or: Why is HTML4 such a PITA to get right?
Outline:
* What I know about HTML4 and Django
* Some info about past efforts and discussions
* Thoughts and curiosities about what we can do
What I know about HTML4 and Django
First, let's not let this turn into an argument
On Thu, Aug 20, 2009 at 1:03 PM, Nicolas Steinmetz wrote:
> Maybe you can inspire from the Jobeet [1] tutorial which consists at the
> beginning as an advent calendar (a one hour tutorial published
> everyday). Jobeet is a Job board and allow to deal with all aspects of
> Symfony framework from fr
Take a look at ticket 3011:
http://code.djangoproject.com/ticket/3011
--~--~-~--~~~---~--~~
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
I'm not sure if this is the place but here are some other issues or
questions I have if this were to happen...
* The jQuery question is a big one. I've taken strides to make the
debug toolbar interoperate with other popular JS frameworks (mootools
and prototype, namely). But if jQuery were deci
On Tue, Aug 11, 2009 at 7:01 AM, Russell
Keith-Magee wrote:
> Firstly, there is the simple issue of ownership and copyright.
> Obviously, those that have written DDT components that are to be
> included need to be onboard with this idea.
On this point I've strived to be pro-active (thanks to Jaco
At the end of the 4th step of the tutorial, it lists some tutorials
that are upcoming:
Coming soon
===
The tutorial ends here for the time being. Future installments of the tutorial
will cover:
* Advanced form processing
* Using the RSS framework
* Using the cache framework
Hi Django Devs,
I saw that ticket[1] made it into the 1.1 list and I was drawn to it.
I have a project that will be doing some mass sending of emails soon,
so I could definitely use something more than what is currently there.
Firstly, the title simply says it wants the ability to disable emails
On 10/30/08, Thomas K. Adamcik <[EMAIL PROTECTED]> wrote:
> If django where to ship something like this __file__ would point to somewhere
> within the installation folder of django, which is obviously not what we
> want.
Not necessarily true. If this code were in the settings.py from the
proje
On 10/28/08, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
>
> On Mon, Oct 20, 2008 at 12:33 PM, Rob Hudson <[EMAIL PROTECTED]> wrote:
> > I think decoupling messages from contrib.auth is a worthy step to
> > making auth a little bit more reusable.
>
> Agreed
On Mon, Oct 20, 2008 at 11:33 AM, Rob Hudson <[EMAIL PROTECTED]> wrote:
> * Should a pre-existing reusable app (like django-notification[2])
> be used/considered instead?
> [2] http://code.google.com/p/django-notification/
I actually meant to link to the django-notices app
Hi Devs,
I just posted a question on Django users about how to best remove the
extra query to auth_messages on every request while still using
contrib.auth and contrib.admin in my own code[1]. This led me to the
thought that contrib.auth should follow the reusable apps mantra of do
only one thin
Hi Devs,
At DjangoCon it was mentioned that you were working on a process for
nominating or approving 3rd party Django apps to be pulled in as
official contrib apps. I'm curious if that's been worked out yet.
Thanks,
Rob
--~--~-~--~~~---~--~~
You received this me
On 9/9/08, Simon Willison <[EMAIL PROTECTED]> wrote:
> http://code.google.com/p/django-html/
As a 3rd party app this is awesome. It's simple and clean and doesn't
require much from the user.
But as part of Django itself, it seems like fixing django.forms (the
source) would be a better solution
On 9/9/08, Simon Willison <[EMAIL PROTECTED]> wrote:
>
> Back in March there was a discussion about providing a way to output
> django.forms widgets as HTML (at the moment they always use XHTML,
> which leads to nastyness on sites using an HTML doctype):
After I read that I created the doctype
OSCON is July 21st to the 25th in Portland, OR. It's not in a date
range listed but I'm curious if something could be arranged there? If
not a sprint maybe a BOF or just a meet and greet?
On Jun 25, 3:58 pm, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]>
wrote:
> Hi folks --
>
> I'm setting up sprints
On 6/19/08, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
> Please don't try to turn this into a "Django should use
> Git!" thread; if you do I'll just ignore you. We're not switching from
> SVN any time in the foreseeable future.
I hope you are nearsighted and the foreseeable future isn't too
On 6/19/08, Rob Hudson <[EMAIL PROTECTED]> wrote:
> Use the `-T`, `-t`, `-b` flags, or `-s` if the project has a "standard
> layout". This should bring over branches and tags as well.
I forgot to reference the man page (which was in my clipboard):
http://www.kernel.or
On 6/19/08, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
>
> On Thu, Jun 19, 2008 at 11:55 AM, [EMAIL PROTECTED]
> <[EMAIL PROTECTED]> wrote:
> > Is this only going to offer the trunk branch?
>
>
> Until I learn more about Git, yes :)
>
> If you know the correct incantation to add other git-sv
On 6/10/08, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
> However, if we _ever_ want to get v1.0 out the door, we're going to
> have to draw the line somewhere. This wouldn't be a trivial change -
> at the very least, it will require a bit of discussion to work out
> exactly what we should
Hi Dango devs,
I wanted to publicly apologize for the framing of my question... I
meant it to be humorously provocative but I fear it could be easily
misread to be rude and annoying, and not easily turned into something
productive. That wasn't my intention.
I am curious if anyone thinks having
Posting this here rather than someone's blog post comments:
Just a note up front, Django has completely changed the way I build
websites and I'm totally enamored with it, but I'm trying to think of
how official releases could have benefitted myself in my situation and
this is what I came up with.
On 6/7/08, Jeremy Dunck <[EMAIL PROTECTED]> wrote:
> On Sat, Jun 7, 2008 at 7:23 PM, Rob Hudson <[EMAIL PROTECTED]> wrote:
> > Where I work we use 0.96 (though I use trunk on my personal projects).
> > We use 0.96 because we have up to 12 separate Django projects
On Sat, Jun 7, 2008 at 4:45 PM, Tim Chase
<[EMAIL PROTECTED]> wrote:
> I'm not sure blessing it with a number does much but pander to
> folks that are scared to make a tough call:
>
> Use 0.96: blessed with a magic number, but old and not much like
> 1.0 will be
>
> or use Trunk: suggested (but
On Sat, Jun 7, 2008 at 1:03 PM, Jacob Kaplan-Moss
<[EMAIL PROTECTED]> wrote:
> One suggestion is to assign to "foo.bar_id" instead of "foo.bar"; that
> skips the validation hook. But if you've got more suggestions I'm
> listening...
I got around it just by putting the FK assignments in a try bloc
On Sun, Jun 1, 2008 at 8:11 AM, Ivan Sagalaev
<[EMAIL PROTECTED]> wrote:
> Why not defer it to save()? Currently you can assign invalid values to
> other fields and it won't break until save():
>
> obj.time = 125 # Ok
> obj.save() # ProgrammingError
>
> And many things even won't break at all
On Sat, Jun 7, 2008 at 12:06 PM, Jacob Kaplan-Moss
<[EMAIL PROTECTED]> wrote:
> * Start a "train release" schedule: schedule a couple of 1.0 betas, a
> rc or two, and then a final release. Features that are done by the
> dates get released, those that aren't, don't. Make these dates
> aggressive b
Regarding this blog post:
http://www.technobabble.dk/2008/jun/07/django-importance-releases/
I think the most often reason why I've heard is that it takes time to
create a release, post it, push security patches to it, etc. Which
makes sense, but at the same time there are a lot of valid points
I'm pretty sure this has been beaten to death, and I was going to pass
on sending this in, but this paragraph made me ask, "What would it
hurt to ask?":
{% block quote %}
Unfortunately, sometimes you are not fully in control of the content
you produce. For example, this very blog, published with
I'd like to know too. I especially liked both of Simon Willison's
ideas of 1) Template tags for form rendering, and 2) Outputting and
setting of a _doctype variable that the template tags use to decide
what kind of HTML to output.
If nobody has officially started anything, could we set up a Goog
I don't know if this should go to devs or users but I wanted to ask...
Now that queryset-refactor has implemented model inheritance (and will
soon be in trunk), will the recommended way to tie in new columns to
contrib.auth.models.User change? For example, if we want to add in
profile informatio
Simon Willison wrote:
> Of course, this behaviour is documented... but I think it's reasonable
> to expect that many people will miss that part of the docs.
Where? I didn't know about this and feel like I've read most of the
Django documentation and the Django book. I'm purposefully looking
for
Just a note: I'm not going to champion this one since I do know
regular expressions. I simply read elsewhere that it is a common
stumbling block for newbies and thought I'd bring it up.
Actually, the regex newbies I know usually just need a few examples to
get them off the ground. E.g. use "[-\
It was discussed previously that making URL matching easier by not
having to understand regular expressions would be a nice goal, and
perhaps a nice 1.0 goal...
http://groups.google.com/group/django-developers/browse_thread/thread/b4c237ad76f9eeca/b9b2acc81fe6e5cf
I just stumbled across yet anoth
On 3/24/08, Alex Koshelev <[EMAIL PROTECTED]> wrote:
>
> Hi, ro60
>
> There is no need in such setting. Just now you can set table engine to
> entire database or in settings.py per-connection with
>
> DATABASE_OPTIONS = {"init_command": "SET storage_engine=INNODB" }
Or to avoid this setting a
On 3/24/08, James Bennett <[EMAIL PROTECTED]> wrote:
>
> On Mon, Mar 24, 2008 at 3:23 PM, Ben Firshman <[EMAIL PROTECTED]> wrote:
> > Would proposing a complete replacement be a tad too controversial for a
> GSoC
> > project?
>
>
> Yes. It also wouldn't succeed as a project, because it's the
If it's common advice to make apps portable and bundle urls along with
an app, shouldn't manage.py startapp also drop in a default urls.py
file?
I realize it's simple to create a skeleton file yourself, but if
manage.py did it, it's one less thing to think about and do, and also
promotes good url
On 12/18/07, Vinay Sajip <[EMAIL PROTECTED]> wrote:
> A reasonable approach would be that the media root for any app is
> conventionally /media/app_label. This is easily organisable under
> Apache/mod_python by having a single media location /media/ for which
> you do a "SetHandler None", then cre
On 12/13/07, Empty <[EMAIL PROTECTED]> wrote:
> For those that enjoy an audio dump, for a commute or something, I've
> put together a podcast called This Week in Django. It's a bit
> experimental at this point, but I'm playing around with different
> ideas. You can find more here:
>
> http://blo
Would it be too much to start thinking about marketing for the 1.0
release? By marketing, I mean, screencasts, t-shirts, coffee mugs.
Possibly a not-for-profit entity to pipe whatever proceeds or
donations through to help support Django coding, or have paid
bounties, etc.
IIRC, some of these thi
On 12/11/07, Patryk Zawadzki <[EMAIL PROTECTED]> wrote:
> If you parse it with a true XML parser then the content gets unescaped
> on delivery. Then feed it to Python's BeautifulSoup to do anything
> else.
I'm using ElementTree to parse the RSS and you're right about the
unescaping. Thanks!
--~
On 12/11/07, Patryk Zawadzki <[EMAIL PROTECTED]> wrote:
> Why not use
> http://code.djangoproject.com/timeline?ticket=on&max=50&daysback=90&format=rss
> ?
I am actually. But I did just realize the description fields has the
full details of the comment. The description field would require a
bit
On 12/11/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
> Looks like a good start. If you can sort out the details of how to
> manage this as a group effort and get a regular publication rhythm
> going, I'll poke Jacob and Adrian and see what we can do.
Great. Thanks. I did ask Jacob if it
On 12/8/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
> The same is true of a weekly Django update message. There is
> absolutely nothing stopping you from writing a weekly blog message and
> publishing it somewhere.
I posted a quick proof of concept:
http://rob.cogit8.org/blog/2007/Dec/10/d
On 12/8/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
> I'm not sure I'd be a fan of a completely automated mechanism - Django
> has a certain sense of style and finess that isn't conveyed by simply
> aggregating all updates into a single message.
The intent of my first message was to propos
Hi Devs,
I've been missing the weekly updates that Clint Ecker was doing and so
I thought I'd write in to pitch an idea and offer some help if I
could. I'd say a good goal to keep these going would be to not rely
in a single person as much. If we can come up with a weekly format
that is not ver
On Sep 27, 12:53 am, eXt <[EMAIL PROTECTED]> wrote:
>I found that there was a change in
> django.contrib.contenttypes.management.py which adds:
I wrote that patch so I can at least respond but I think this bubbles
up into a design decision for Django...
> This causes removal of my custom con
Hi Devs,
Is model.objects.all().delete() optimized to use DELETE FROM? I'm
only asking because I was trying to clear a table with about 20k
records and it took minutes rather than seconds. I'm using MySQL as
the backend. I'm not very familiar with the database query mechanism
and I know it's b
On 9/15/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
>
> On Sun, 2007-09-16 at 00:36 +, Rob Hudson wrote:
> > http://code.djangoproject.com/ticket/2465
> >
> > I'm running into this and it makes sense to me that select_related
> > should do thi
http://code.djangoproject.com/ticket/2465
I'm running into this and it makes sense to me that select_related
should do this right. I'm curious of Adrian's comment about this
involving a bunch of LEFT JOINs and why that's a bad thing?
Thanks,
Rob
--~--~-~--~~~---~--
> However, we're always interested in any way to make the documentation
> better, so if you can come up with a way to make this idea work, we
> can take a look at it.
That's the hard part and was hoping someone would have a bright
idea. :) The best idea I've had is to spell out the full path to
Hi Devs,
One of the things I'm always stuck with when reading the docs is
knowing where to import the described methods or objects from. For
example, just now I'm working on Q objects and just read the
documentation but don't know where they live without having to jump
into the source of where I
Hi Devs,
I just bumped into this and can see both sides so I'm posting here...
I'm working on a project that wants a list view to have configurable
num_per_page for pagination. I set it up to pull from the GET (eg: /
search/category-slug/?per_page=10). What I did was check for the
existence of
I've approached this like the following, though I'd be interested to
hear if there is a better way. I like putting the environ settings in
the script itself so everything is self contained (could be run from
cron, etc)...
At the top of my Python file I have this:
import os, sys
# Connect to Dja
I did a search and found this thread:
http://groups.google.com/group/django-developers/browse_thread/thread/49a6b99dbcea4364/dbaa965c304feed3
It looks like there was general support for the idea but the thread
died and as far as I can tell there was never any decision or ticket.
Just tonight I f
I don't know if one problem might be that Django's built-in server
isn't multi-threaded (or if it's another part of the chain) but you
can try to apply the patch in this ticket as a test...
http://code.djangoproject.com/ticket/3357
Note: The patch is a bit old and may need to be adjusted slightly
Hi Devs,
I'm working on a patch for #5177
(http://code.djangoproject.com/ticket/5177) which will clean up
orphaned content types and Malcolm questioned, "What happens if a
model has Meta.app_label set?" and further went on to explain that it
was never clearly determined if app_label should only r
On Aug 15, 4:44 pm, "Russell Keith-Magee" <[EMAIL PROTECTED]>
wrote:
> I look forward to seeing your patch! :-)
First attempt is in this ticket...
http://code.djangoproject.com/ticket/5177
I do need to test a bit further on a real project and with users who
have permissions to see how it all man
On 8/15/07, Deryck Hodge <[EMAIL PROTECTED]> wrote:
> Why not, rather than adding another option in django.core.management,
> have the contenttypes app do this? The existing post_syncdb hook
> could be extended to clear unused content types as well as create new
> ones.
>
> You would have to reme
On 8/15/07, Collin Grady <[EMAIL PROTECTED]> wrote:
> Shouldn't really be an issue with his scenario though, since he said
> this was during initial dev on the data model, so he wouldn't even have
> much (if any) data yet :)
Right, but when it comes time for the next app I create in that
project,
On 8/15/07, Collin Grady <[EMAIL PROTECTED]> wrote:
> Wouldn't reset do that?
>
> ./manage.py reset auth contenttypes
I haven't tried that but that looks like it would clear those tables
completely vs. purging only the unused tables.
Would following that with a syncdb then restore the content ty
PS: I should add before Malcolm tells me, "We accept patches" that I'm
willing to code this up for submissions if the idea is generally well
received. :)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django deve
One of the things I typically do when starting a new project/app is to
spend some time adjusting and tweaking the data model. One thing I
run into sometimes when I change my model name is leftover content
types in the database and also in the permissions. It's a bit of a
pain removing these manu
I've been watching the development with interest.
I'm probably your user #1 with curiosity that might lead to user #2.
I know the basics of what Atom is and what AtomPub is (but not quite
clear on where REST and full AtomPub differ or relate -- they sound
like they have a lot of overlap where may
FYI: I've also contributed a patch for this ticket:
http://code.djangoproject.com/ticket/3624
It adds some extra support so the feeds don't need to hit the
filesystem just to pull in a simple template.
-Rob
On Aug 7, 4:28 am, jorjun <[EMAIL PROTECTED]> wrote:
> Done. Thanks for guidance.
>
> >
On Aug 2, 12:55 am, Michael Radziej <[EMAIL PROTECTED]> wrote:
> I'd still suggest a 'default off' policy at least when autoescape is
> introduced, just to give users a transition period. A 'default on' policy
> means that autoescape will break a lot of custom template tags and filters.
> The poli
On Jul 29, 2:54 pm, Simon Greenhill <[EMAIL PROTECTED]> wrote:
> Hmm... off the top of my head -
[snip]
Cool, I've included those as an example of more details.
Feel free to update the following if anyone feels it needs it...
http://code.djangoproject.com/wiki/DjangoSuccessStories
Now we just n
On 7/28/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> It's definitely up for discussion, and I'm not tied to the current
> tutorial in any way. My personal preference is to replace the official
> tutorial with the first few chapters of the Django book, once that's
> been published, because thos
On 7/29/07, Simon G. <[EMAIL PROTECTED]> wrote:
> 4) Politely ask some of the big Django sites if they could answer 5 or
> 6 questions (e.g. pownce, tabblo, etc)
>
> If you get a few "big" names in there, then others should follow.
What would the 5 or 6 questions be?
-Rob
--~--~-~--~---
On 7/28/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> > 1) Set up a page on the wiki with instructions and suggested outline
> > of a success story.
> > 2) Post a "Call for Success Stories" somehow, maybe via the weekly updates.
> > 3) Keep an eye on the page and linked pages.
>
> If you're
> Now, there's one small wrinkle that may prove unfortunate for you: in
> the Django community, it's pretty much established practice to equate
> good ideas with a volunteer offer. By this precedent, I do believe
> you've volunteered to gather this material .
>
> Seriously, though -- if it's somet
Hi Devs,
One thing that came out of the Django Meet-up at OSCON was someone
asking for advice on how to convince their superiors that Django is a
good choice. This obviously depends on the needs of the individual or
shop, but I was wondering if we could add a section to the Wiki for
success stor
Hi Devs,
I've been recommending Django to web developer friends. I typically
first point them to Jacob's excellent video on Google for the
background on Django (with the caveat that some code might be out of
date but the general history and Django philosophy is well
represented)...
http://video.
Hi Devs,
In http://code.djangoproject.com/wiki/VersionOneFeatures I see Windows
Installers listed with no leader and no start status. I'm pretty
comfortable building installers using NSIS (nsis.sf.net) as we do that
where I work and could chip in here.
Has it been discussed what the installer s
On Jul 19, 2:10 am, Michael Radziej <[EMAIL PROTECTED]> wrote:
> Was git-svn easy to set up? I'm having issues with its ugly sibling
> "git-svnimport" ...
On a Mac with MacPorts, very easy:
$ sudo port install git-core +svn
Anywhere else I'm not sure but the above suggests that git-svn is a
After going to a git presentation by Randal Schwartz and watching the
video by Linus on git, I decided to play with it some for a patch I'm
testing in Django. I got git and git-svn installed on my Mac, pulled
down the Django source and started a new branch for the patch I'm
working on.
What's *r
I've been playing with this a little today and I'm curious... does
this work on any database backend? The Django db stuff is a bit
magical to me, but in the path I'm following in the code, I don't see
anything that tells it to look at order_with_respect_to if ordering ==
'_order'.
I have this si
I'd like to hear what others think of this approach b/c it makes a lot
of sense to me and does seem much easier in that:
1) The newly defined user object is in request
2) There's one place to get user info
Thanks for sharing,
Rob
--~--~-~--~~~---~--~~
You receiv
On Apr 6, 3:51 am, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> [An unproven gut feeling: keeping a small reminder, however subliminal,
> that things are relational-database backed is actually a good idea. It
> will stop widely read people from thinking there is a true object
> backing store.
> Ok - initial opinion appears to be anti configurability and anti
> changing the default. Another option is to introduce a different tag
> for the 0-spaces case. Opinions? Suggestions for names? Spaceless is
> the obvious choice, but that name is taken :-)
My thought was:
"spaceless" is no spac
> Ok - initial opinion appears to be anti configurability and anti
> changing the default. Another option is to introduce a different tag
> for the 0-spaces case. Opinions? Suggestions for names? Spaceless is
> the obvious choice, but that name is taken :-)
My thought was:
"spaceless" is no spac
On Mar 7, 11:15 am, David Danier <[EMAIL PROTECTED]> wrote:
> AFAIK the queries are logged without quoting but executed correctly.
> (You can see this, if you have a SQL-error and the DB-backends throws an
> exception with the real query)
So somewhere else in the ORM it fixes the quoting before i
I was reviewing all the SQL calls in my page views by taking advantage
of the context variable "sql_queries" when DEBUG=True.
I found this query that isn't quoted correctly (I trimmed out some
stuff to make this shorter):
SELECT
-- various fields listed here
FROM
`page_content`
INNER JOIN
I like it... I had to do a all encompassing "except" just the other
day because IntegrityError was in MySQLdb.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send e
> Could this be related to #2874 ?
2874 looks related in that it is another bug resulting from a similar
type of circular table relationship.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" grou
On Feb 9, 3:12 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> So after some back and forth about whether this should or shouldn't
> work, there didn't seem to be any resolution. Your gut feeling looks
> right to me Rob: it should probably work as you expect (no collision),
> although it won't
1 - 100 of 171 matches
Mail list logo
