Re: Reversed url lookup: would be nice to return more than the resulting url.
Just in case someone is needing something like this too, i created a patch: http://code.djangoproject.com/ticket/2615 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Test framework and dispatching benchmarks
Hi all,As a result of some performance concerns, Adrian has reverted the template rendering signals that were part of the recent test framework changesets. I was under the impression that the overhead of an dispatching a signal with no handlers would be negligible, so, to validate (or invalidate) Adrian's concerns, I've done a little benchmarking, and I have three options for moving forward. On my machine, constructing and rendering a 'text only, empty context, no tags' template takes approx 0.16ms. Constructing and rendering a trivial template (the 'polls/template.html' from tutorial 3, using dictionaries in the context instead of QuerySets) takes 1.2ms.If the dispatcher has no handlers registered, a call to dispatcher.send() takes on the order of 0.1ms. If you set up 100 signals, and register 5 handlers on each of those signals, dispatching a signal which has no handlers still takes on the order of 0.1ms.So; dispatching isn't completely free, but it is fairly low impact. Keep in mind that these are pretty trivial templates, and the benchmark numbers I have presented don't take into account the time required for database processing, view processing, disk access and the like, so in practice, the difference will likely be much larger.I can see 3 options.Option 1 - Don't worry about the overhead. Always emit the template rendering signal; the testing system is the only mechanism that will listen to it. The time spent processing a signal that is ignored is at least an order of magnitude less than template rendering time, likely much less when the full view evaluation process is considered. However, any loss is still a loss, and every little bit adds up when you are being Slashdotted. Option 2 - Add a boolean condition to shortcut the signal dispatch:def render(): if settings.TESTING : dispatcher.dispatch(...) return This reduces the overhead in the dispatcher system itself, at the cost of a single boolean comparison. However, it does make a special case of testing in general code. Option 3: In the setup of the test target in django-admin, replace Template.render with a template rendering method that dispatches the required signal. def test_renderer(self, context): dispatcher.dispatch(...) return self.render_internal(context)Template.render_internal = Template.renderTemplate.render = test_rendererThis results in zero impact unless you are actually testing. However, it does mean that unit tests are not guaranteed to be standalone. To overcome this, the installation of the test renderer could be put into an initialization method somewhere in the test module, with the documentation describing how to configure Django for testing for those that want to use a external testing tool. Personally, I find myself leaning towards option 3 - outside of testing, I can't see any use case for a template-rendering signal, and I don't like special cases. Instrumentation of the rendering system as part of the test framework setup seems an appropriate solution. Comments? Questions? Alternatives? Preferences?Yours,Russ Magee %-) --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Test framework and dispatching benchmarks
On 8/29/06, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: > Personally, I find myself leaning towards option 3 - outside of testing, I > can't see any use case for a template-rendering signal, and I don't like > special cases. Instrumentation of the rendering system as part of the test > framework setup seems an appropriate solution. > My personal preference is for option 3. While testing is incredibly important, a site with decent traffic will spend 99% of its execution time, over its lifetime, responding to actual requests, as opposed to running tests. Some might call it premature optimization, but I'd prefer not to see something go in that will essentially result in wasted cycles 99% of the time. And remember that even for option 2, there's not just the cost of a boolean comparison. There's also the cost of a namespace lookup to get 'TESTING' from 'settings', unless you want to do a 'from settings import TESTING'. Jay P. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Test framework and dispatching benchmarks
+1 to option 3. Jacob --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
What is the Right Way to handle DECIMAL fields?
In a project I am working on, we need to store monetary values in the database, and we want to avoid floats altogether so that we don't lose precision or have representation errors. The existing FloatField was not suitable for use, because it would sometimes return floats and sometimes decimals, depending on circumstances. I submitted a ticket & patch, #2365 (http://code.djangoproject.com/ticket/2365) that addresses this by making FloatField work exclusively with floats, and added DecimalField (in db. and forms.) that would work with decimal.Decimal objects. The problem with the latter is that the decimal module is only in 2.4, and django is targeting 2.3 as the minimum support version of Python. To quote from what I wrote in the ticket: > Finally, this patch should work without the decimal module: if the > decimal module is available, then models.DecimalField? attributes will > be decimal.Decimal instances; if not, then they will be strings. If the > user needs to perform arithmetic, then he can call float() and operate > within the accuracy limits of floats, but it's safer not to convert > implicitly. To which Malcom replied: > I don't like the implication of the last paragraph of the previous > comment. It means that every single time you do arithmetic with this > field, you need to either test that you are running on Python 2.4 or > call float(). This is a huge burden on the developer. It has to work a > bit more transparently than that. So, which is better to do if the decimal module is not available: is it better to return a string from a DecimalField, sacrificing convenience for a guarantee of exact representation, or return a float so that the user can do arithmetic without hassle? I'm of the opinion that the former is better, as it requires the developer to explicitly take actions that may result in a loss of information; and for those cases where the developer either needs floats or doesn't care as much about the accuracy, he can use models.FloatField, which will consistently return floats. What do others think? Andrew --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Django Test framework commits (r3658-r3661)
On Mon, 2006-08-28 at 01:14 -0700, [EMAIL PROTECTED] wrote: > Hi Russ, > > Nice work! > > FYI I submitted a patch (#2490 [1] ) a while ago to get runtests.py to > produce an error if no DJANGO_SETTINGS_MODULE is in the env. Not sure > if this is something you want, but I've updated it to work post r3661 - > it does make it a little bit easier to work out how to run the tests! > > Next - I'm getting failures with an SQLite database on: > FAIL: Doctest: modeltests.many_to_many.models.__test__.API_TESTS > FAIL: Doctest: modeltests.many_to_one.models.__test__.API_TESTS > > Both of these look like they're failing due to SQLite not being able to > handle COUNT(DISTINCT(fieldname)). Are you running an old SQLite version? My recollection is that SQLite introduced support for count(distinct(...)) about a year ago now. The main distribution I believe is affected are people running old Debian setups (maybe Debian testing is still affected, I don't know). There's an old thread about this on this list. In short, it's a little hard to support the older SQLite versions, because they would end up giving wrong answers for certain queries. We never really resolved it one way or the other, though, so a minimum version number isn't correctly documented. One SQLite oddity here is that SQLite does not support count(distinct(*)) -- you need to include a column name. Not sure if that is the problem you are seeing or not. In any case, we have been testing count(distinct(pk_field)) queries for a number of months now as part of the test suite, so if you could check a subversion checkout from before Russell committed his changes and see if the results have actually changed, that would be handy. When I was originally looking over these patches, I tested against SQLite, amongst other things, and saw no failures, so it would be interesting to know what is different on your system if it's something other than an older SQLite installation. Regards, Malcolm --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: allow simple_tag to set context?
On Tue, 2006-08-29 at 14:49 +0800, Slowness Chen wrote:
> simple_tag and inclusion_tag make writing simple template tags much more
> convenient.
> As the document says, "Another common type of template tag is the type that
> displays
> some data by rendering another template", e.g.
>
>
> {% for choice in choices %}
> {{ choice }}
> {% endfor %}
>
>
> But if there are many places in which you need to use inclusion_tag , it
> gets annoying that you have to
> extract all these *short and simple* snippets into separate template files.
> If simple_tag can also
> set context, that will be more convenient. Something like:
>@register.simple_tag(sets_context=True)
>
> Just some thoughts. any comments are welcome.
Seems reasonable to me. If you make a ticket for this and assign it to
me (mtredinnick in Trac), I'll handle this.
Cheers,
Malcolm
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: 3 patches I've added
On Mon, 2006-08-28 at 10:12 -0500, Tom Tobin wrote: > On 8/28/06, Joel Heenan <[EMAIL PROTECTED]> wrote: > > > > I have noticed there is a great number of patches like mine that don't > > ever seem to be reviewed and all seemed to be assigned to Adrian but > > he seems to be concentrating on new features at the moment. As someone > > who wants to contribute to Django and is happy to fix these bugs > > should I just keep going submitting these patches or is there someone > > I should enter into a dialogue with about getting them committed? > > http://www.djangoproject.com/documentation/faq/#i-submitted-a-bug-fix-in-the-ticket-system-several-weeks-ago-why-are-you-ignoring-my-patch > > In summary: the core devs are really busy, and if they haven't done > anything with your ticket it just means that they haven't gotten a > chance to go over it in detail. If a ticket is definitely unsuited > for Django, they would have closed it immediately. > > From my own experience watching Django's timeline, the core developers > tend to go on "rampages" every so often and address many tickets at > once; if you submitted these tickets recently, there's a good chance > they'll get some love next time that happens. :-) Tom's right here, although I'm not sure I'd use the word "rampage". :-) We do tend to fix a bunch of bugs all at once when we get a moment (for a recent example, look at all the commits Adrian did yesterday in a short period of time). For my own part, I've been busy with my pay-the-bills work, so I've not had as much time to look at Django itself over the last couple of weeks. I hope to suck a bit less on this front later this week and next week and will try to get some tickets closed in the process. We've just hit a period recently where most of the main committers have been busy for various reasons. Life's like that sometimes. Sorry. Cheers, Malcolm --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: OneToOneField and non-integer primary keys
Hey James, On Sat, 2006-08-26 at 23:51 -0500, James Bennett wrote: > Someone in IRC tonight was running into the problem described in > ticket #343 tonight, and after a quick test I can verify it's still > happening in trunk. I'm blacklisted in Trac right now (Tom's looking > into it), so I'll post some thoughts here. > > The root of the problem is that OneToOneField inherits from > IntegerField, so regardless of the actual field type of the related > model's primary key, the OneToOne wants to be an integer and that ends > up breaking things. There are two solutions I can think of for this: > > 1. Re-implement OneToOneField to inherit directly from Field instead > (foreign keys do this, which is why I assume they don't run into the > same problem). > 2. Re-implement OneToOneField to inherit from ForeignKeyField. This > makes more sense to me, personally, because it ends up being a foreign > key in the database anyway. At first glance I think this would also be > less work, but I haven't gotten into the code deeply enough to be > certain. > > Anyone have a strong preference either way before I start working on patches? Sorry for the delayed response -- I'm just catching up on a week or so of django email. My two cents would be to do option 2 if it's feasible. It feels a bit more natural to me for the reasons you mentioned. The only potential problem I can see is when we implement multi-column primary keys, which is something I want to look at eventually. OneToOne fields are currently compulsory primary keys. I have to create a similar, but not identical, class for model inheritance one-to-ones (multi-inheritance means they can't all be primary keys) and it occurred to me at the time that one-to-one to models with multi-column keys are going to be interesting, too. However, I suspect that right now the correct response is to punt on that and just reimplement the current functionality. I'm only mentioning this in case it helps guide your thinking whilst your neck deep in the code. Cheers, Malcolm --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: What is the Right Way to handle DECIMAL fields?
On Tue, 2006-08-29 at 16:46 +, Andrew Durdin wrote: [...] > To quote from what I wrote in the ticket: > > > Finally, this patch should work without the decimal module: if the > > decimal module is available, then models.DecimalField? attributes will > > be decimal.Decimal instances; if not, then they will be strings. If the > > user needs to perform arithmetic, then he can call float() and operate > > within the accuracy limits of floats, but it's safer not to convert > > implicitly. > > To which Malcom replied: If people don't start putting the second 'l' in my name, there's going to be trouble! > > I don't like the implication of the last paragraph of the previous > > comment. It means that every single time you do arithmetic with this > > field, you need to either test that you are running on Python 2.4 or > > call float(). This is a huge burden on the developer. It has to work a > > bit more transparently than that. > > So, which is better to do if the decimal module is not available: is it > better to return a string from a DecimalField, sacrificing convenience > for a guarantee of exact representation, or return a float so that the > user can do arithmetic without hassle? > > I'm of the opinion that the former is better, as it requires the > developer to explicitly take actions that may result in a loss of > information; and for those cases where the developer either needs > floats or doesn't care as much about the accuracy, he can use > models.FloatField, which will consistently return floats. What do > others think? I wish I had an answer for this one, because I can totally see both sides of the situation and I want the best of both worlds. I'm in the process of porting an existing database application I wrote a couple of years ago over to Django, just to see where the hard problems arise. I've hit the same sort of problem, since this app deals with foreign currency exchanges. I'm seriously considering adding my own custom Decimal field, since I can require Python 2.4 for this app. I'd be a bit loathe to add a Python-2.4-only field to Django core, though. Some thoughts about this (adding custom fields)... Extending Django's existing fields to allow custom derivatives is not too hard (there is one two-line change required in base.py). That would allow external apps to register their own field types (and have it appear as the right field type in the model instances). The hard bit is how to integrate this smoothly with the database creation code. If you (or anybody else) has an idea about how to do that easily (a *concrete* idea -- I've already covered "we should do it" :-) ), it would be worthwhile. Then we could allow people to create their own derived fields for their own use; this is particularly easy when the field derives from an existing Django field, a little harder for custom database fields, but still pretty simple to implement the support in core. Regards, Malcolm --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Ticket 1400
Hi all, There has been no response on http://code.djangoproject.com/ticket/1400 after mine and Simon's comments. I'd like to go ahead and revert that one thing, but can the original committer (Russell) comment? Thanks, Luke -- Parenthetical remarks (however relevant) are unnecessary Luke Plant || L.Plant.98 (at) cantab.net || http://lukeplant.me.uk/ --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Broken internal links e-mails
I'm currently getting tons of 'Broken INTERNAL link' e-mails from my live site, but they are incorrect -- sometimes the 'Referrer' URL doesn't even exist. I suspect it is some rather broken bot making all kinds of random requests, so I'd like to add 'User agent' to the information that is sent in the e-mail, so I could filter these. Is this OK? Is there any other information that other people would find helpful? Thanks, Luke -- Parenthetical remarks (however relevant) are unnecessary Luke Plant || L.Plant.98 (at) cantab.net || http://lukeplant.me.uk/ --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Extending the Site object
I made a patch, in case anyone else also wants this. http://code.djangoproject.com/ticket/2618 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Ticket 1400
On 8/29/06, Luke Plant <[EMAIL PROTECTED]> wrote: > There has been no response on http://code.djangoproject.com/ticket/1400 > after mine and Simon's comments. I'd like to go ahead and revert that > one thing, but can the original committer (Russell) comment? I'm +1 on reverting that change. The string 'False' should not evaluate to False. 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 -~--~~~~--~~--~--~---
Re: Broken internal links e-mails
On 8/29/06, Luke Plant <[EMAIL PROTECTED]> wrote: > I'm currently getting tons of 'Broken INTERNAL link' e-mails from my > live site, but they are incorrect -- sometimes the 'Referrer' URL > doesn't even exist. I suspect it is some rather broken bot making all > kinds of random requests, so I'd like to add 'User agent' to the > information that is sent in the e-mail, so I could filter these. Is > this OK? Is there any other information that other people would find > helpful? That's cool by me -- there's a patch at http://code.djangoproject.com/ticket/2602 . The patch looks OK to me as is, other than the fact that there's no space after "request.get_full_path(),". (Can you tell I'm anal?) 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 -~--~~~~--~~--~--~---
Integrating Django and SQLAlchemy
Hi all, Spawned by the recent discussion of the big picture of Python Web frameworks, we've decided to start a new branch of Django development that uses SQLAlchemy (http://www.sqlalchemy.org/) as the underlying database library. Robin Munn, author of an excellent SQLAlchemy tutorial (http://www.rmunn.com/sqlalchemy-tutorial/tutorial.html) and heavy contributor to Django several months ago, has agreed to be the lead developer on this branch. I'm sure he'll bring up any issues/implementation questions on this mailing list, and if you want to help out in some fashion, make yourself known! Here are some notes about implementation: * The Django database API would not change, and the SQLAlchemy backend would be *optional*. The point of the SQLAlchemy backend would be to expose the underlying SQLAlchemy API if you need to do something truly complicated, rather than having to fall into raw SQL. * At the moment, a Django model inherits from django.db.models.Model, and convention is to put "from django.db import models" at the top of your models.py file. I think it'd be smoothest (and really cool) if people were able to switch that to "from django.contrib.sqlalchemy.db import models" and not have to change any code. In other words, SQLAlchemy models would be instances of django.contrib.sqlalchemy.db.models.Model rather than django.db.models.Model. * As that implies, this would be an *optional* add-on -- the existing model machinery would stay put. I.e., people could still use Django without SQLAlchemy, and that would be the default. I wouldn't rule out a full migration to SQLAlchemy (i.e., making it default) in the future, but we'd rather not add a dependency at this point. * A model object's "_meta" attribute should be preserved. (This is the metadata about the model.) Although it starts with an underscore, there's enough code out there using it that makes it a de-facto standard part of the database API. * As for refactoring the existing code to add hooks for SQLAlchemy -- that's fine as long as it's not too much of an added overhead for non-SQLAlchemy users. * This branch will be called "sqlalchemy" in the Django Subversion repository. 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 -~--~~~~--~~--~--~---
bump - django unicode branch...?
hi, (sorry to open this topic again, i understand that the core developers have many other things to do etc...) around 2 weeks ago we had this thread there about creating a branch for the django-unicode conversion is it still the plan? i'd just like to know what's the status... a "yes, we'll do it, but haven't found the time to create the branch yet, wait a little" answer is enough :) gabor --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Broken internal links e-mails
The source IP would be useful as well. other things which *may* be useful might be the auth_user_id and session_key of the request record. FWIW.. there is a rouge bot going round in Australia which 'guesses' URLs based on what it sees in javascript. and i've also seen some spam bots guessing urls to add comments/ trackbacks as well. regards Ian On 30/08/2006, at 7:03 AM, Adrian Holovaty wrote: > > On 8/29/06, Luke Plant <[EMAIL PROTECTED]> wrote: >> I'm currently getting tons of 'Broken INTERNAL link' e-mails from my >> live site, but they are incorrect -- sometimes the 'Referrer' URL >> doesn't even exist. I suspect it is some rather broken bot making >> all >> kinds of random requests, so I'd like to add 'User agent' to the >> information that is sent in the e-mail, so I could filter these. Is >> this OK? Is there any other information that other people would find >> helpful? > > That's cool by me -- there's a patch at > http://code.djangoproject.com/ticket/2602 . The patch looks OK to me > as is, other than the fact that there's no space after > "request.get_full_path(),". (Can you tell I'm anal?) > > Adrian > > -- > Adrian Holovaty > holovaty.com | djangoproject.com > > > -- Ian Holsman [EMAIL PROTECTED] http://garden-gossip.com/ -- what's in your garden? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Integrating Django and SQLAlchemy
On 8/29/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > > Hi all, > > Spawned by the recent discussion of the big picture of Python Web > frameworks, we've decided to start a new branch of Django development > that uses SQLAlchemy (http://www.sqlalchemy.org/) as the underlying > database library. > > Robin Munn, author of an excellent SQLAlchemy tutorial > (http://www.rmunn.com/sqlalchemy-tutorial/tutorial.html) and heavy > contributor to Django several months ago, has agreed to be the lead > developer on this branch. I'm sure he'll bring up any > issues/implementation questions on this mailing list, and if you want > to help out in some fashion, make yourself known! *waves* Hi all! As Adrian said, if you have any suggestions to make, even if it's as simple as what you'd like the API to look like, now's the time to make them. I'm only *just* getting started on this, and right now I'm just plunging into a refresher course on what's changed in Django since I last looked at it -- which was more like a year ago than the "several months ago" that Adrian just said. :-) The notes on implementation that Adrian posted pretty much match what I'm thinking at this point. The plan is to make this 100% API compatible (if possible -- you never know what will turn up once you start implementing some idea), so that existing code doesn't need to change. But if you want access to the underlying SQLAlchemy objects to do something like a nine-table query involving five LEFT OUTER JOINs and two subselects, well, you should be able to do that as well. One quick request: I don't think I'm going to have time to read the entire django-developers list, since I do have other commitments (such as my day job, which isn't Django-related). So if you have a suggestion about the SQLAlchemy branch, I'd appreciate it if you put the word "SQLAlchemy" in the subject line somewhere. I'll have a GMail filter set up to catch those, and I *will* read all the SQLAlchemy threads in django-developers. And probably even answer them! ;-) I also don't think I'll be able to commit to being on IRC much, or even at all. That may change in the future, but I make no promises on that score. If you want to contribute, or even just make requests, the best way to get in touch with me will be via the django-developers list. (And make sure "SQLAlchemy" is in the subject line so that I see it). I welcome your comments! -- Robin Munn [EMAIL PROTECTED] GPG key 0xD6497014 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Too Much Custom SQL
On 8/29/06, bradford <[EMAIL PROTECTED]> wrote: > > Hi, it seems like I'm constantly writing custom SQL code for everything > because the django ORM cannot handle a lot of my requirements (which is > perfectly understandable). Would it be such a bad idea to add an api > to the django orm that's similar to SQLAlchemy? I don't like having to > create cursors all of the time. That's an idea that's in the works. I just started talking to Adrian about it a few days ago, and he just made the official announcement in the "Integrating Django and SQLAlchemy" thread. If you have any suggestions as to how you'd like the API to look, I would welcome your comments. See that thread for more details. -- Robin Munn [EMAIL PROTECTED] GPG key 0xD6497014 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Broken internal links e-mails
On Tuesday 29 August 2006 22:57, Ian Holsman wrote: > FWIW.. there is a rouge bot going round in Australia Since bots don't normally have colours, I'm guessing that must mean a Communist bot. No doubt it's part of some international plan to undermine capitalism, those pesky Communists at it again... :-) Luke -- Parenthetical remarks (however relevant) are unnecessary Luke Plant || L.Plant.98 (at) cantab.net || http://lukeplant.me.uk/ --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Integrating Django and SQLAlchemy
Robin Munn wrote: > > The notes on implementation that Adrian posted pretty much match what > I'm thinking at this point. The plan is to make this 100% API > compatible (if possible -- you never know what will turn up once you > start implementing some idea), so that existing code doesn't need to > change. But if you want access to the underlying SQLAlchemy objects to > do something like a nine-table query involving five LEFT OUTER JOINs > and two subselects, well, you should be able to do that as well. hi, this is great news... could you show some example code how would it work? like without sqlalchemy you would have to do this in raw sql, but with django+sqlalchemy, you could do that things like that? because i checked the sqlalchemy tutorial, and i see that it is a powerful framework... i just don't currently see how it would interact with django please don't take this wrong, i very much welcome this django/sqlalchemy integration... i'm just curious how exactly would it work... how will i be able to go "deeper" (from django-level into sqlalchemy level) when needed... or ...well..maybe it's too early to ask questions like this :) thanks, gabor --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Integrating Django and SQLAlchemy
This is great news! One question comes to mind first, because I am nothing if not self-absorbed. :) I wonder how much of the multi-db branch I have been working on will be made irrelevant by this. Any thoughts on how the sqlalchemy backend might support connecting different models to different engines? I'd be more than happy to suggest parts of multi-db to steal or adapt, or help with the stealing and adapting, if you're planning to include something like per-model engines in the implementation. More questions: Are you planning on building something like ActiveMapper, or using ActiveMapper, or rolling up a whole new ORM layer on top of the sqlalchemy core? If the last, I have some play-around code (from sqlalchemy around 0.1, though) that I will happily donate in case there is anything stealable or adaptable or so-horrifying-you-know-never-to-repeat-it in there. Great news. JP --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: allow simple_tag to set context?
Done. Ticket #2619 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Ticket 1400
On 8/30/06, Luke Plant <[EMAIL PROTECTED]> wrote: Hi all,There has been no response on http://code.djangoproject.com/ticket/1400after mine and Simon's comments. I'd like to go ahead and revert that one thing, but can the original committer (Russell) comment?I'm sure it seemed like a good idea at the time, but in retrospect, I can't say I can remember why. Best I can figure is that I was having a 'conservative in what you output, liberal in what you accept' kind of day. However, I agree that in this case being liberal introduces more confusion than good. Given popular opinion, I've reverted the change.Apologies for any inconvenience.Russ Magee %-) --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Bump #708: search on IPAddressField with postgres backend is broken
Hi, I hit this bug 10 months ago when I first started using Django and it still hasn't been addressed. As per my comments in the ticket I feel that the use of the inet type in the postgresql backend is a special case that is the root of the issue. Using a char(15) like every other backend would fix the issue and remove this special case. This will definitely cause backwards compatibility issues though. opinions? regards matthew --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
schema-evolution: status?
I had some to make some changes to some models today that would result in schema changes so I decided to give the schema-evolution branch a go. I didn't get far as the script I use to load sample data into my applications failed [1] and trying to manually add data via my public CRUD views failed because 'User' object has no attribute 'is_authenticated'. So it seems the branch is quite far behind the trunk. Any chance of merging the latest trunk changes in the schema-evolution branch? [1] http://paste.e-scribe.com/1384/ regards matthew --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Proposal: Django Apps & Project Repository (again)
Ian Holsman wrote: > luckily? for me I have a bit of time on my hands tomorrow and > possibly monday. > i could get a start on something 'forgish' which could then be used > to critique/improve on. Ian, does this mean you are working on a DjangoForge written in Django? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Thoughts on extensibility of the admin app
One of the cool things about the admin app is the form building, something that I wish were easier. Stuff like the AdminBoundField would be nice to have outside of the admin (I don't know, is this already easy to do?). I am assuming that the admin app will be rewritten with the arrival of the new form system that is in the works, and that the new form system should make admin-like forms more re-usable. Is that correct? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: multiple authentication and session keys
So I hit another little snag today related to this. The contrib.auth.middleware.LazyUser calls contrib.auth.get_user (knowing where to get the user from based on the backend stored in session['_auth_user_backend']), which will return an authentication-backend-dependent user object. This user object shouldn't have to conform to contrib.auth.models.User's interface, yet core.context_processors.auth calls request.user.get_and_delete_messages(). This means that whatever user object I return with my backend must implement a get_and_delete_messages method. Another problem with the request.user.get_and_delete_messages() call is that request.user is a LazyUser. So LazyUser is doing us no good since this call will always put LazyUser to work. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
