Automatic-manipulator, very slow..... design-decision/bug/misunderstanding?
hi, yesterday i was bitten by something in the manipulator-behaviour, which i did not really expect to work that way...and i'm now not sure if i should submit a bugreport, or it should behave like that. also, it's quite possible that i understood this wrong, if that's the case please correct me. let's say you have a model called Owner, that references using a foreignkey a Thing. = class Thing(Model): name = CharField(maxlength=500) = = class Owner(Model): name = CharField(maxlength=500) thing = ForeignKey(Thing) = now let's say you have a LOT of Things... like 5. now, when you call Owner.AddManipulator(), he's going to fetch the WHOLE Thing-table. just to construct the AddManipulator. (well, i REALLY hope that's not the case, but from the db-queries it seems so) i understand that if you want to build later a select-box from this data, then you need all the Thing objects, but in my case that will never happen. and to validate it's input i think it's absolutely unnecessary to load in the whole table. to build the error-message, yes, there it might need it. but only when he really has to build the error message. so, should i report this as a bug, or is this behavior intentional? also, while we're at it... is there a workaround? i tried to experiment with the "follow" parameter, to have the manipulator ignore the thing_id field, and seems to help in the ChangeManipulator case, but in the AddManipulator case it does not help, because then i cannot save the object. is there a way to tell the manipulator to take some additional data for the object-save? 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 -~--~~~~--~~--~--~---
initial SQL thinks it's a format string
Hello Djangonauts,
I've found an issue with initial data and SQLite - if any of the fields
in the initial data has a "%" in it, the import fails. Pysqlite is
apparently processing the query for string formatting args.
Now, I'm *not* getting this error on MySQLdb, but haven't tested
postgres/ado_mssql etc. From [1] I think postgres is also affected, and
would be interested if someone could check this out.
It seems to be quite easy to fix - just do a search and replace for %
to %% around line 352 in django/core/management.py, in
get_sql_initial_data_for_model(). However, I'm not sure what the best
practice for doing RDBMS specific "tweaking/fixing" is - should this be
implemented in something like db/backends//base.py?
Nor am I sure how far you want to go in fixing what appears to be a
pysqlite implementation, uh, wart.
Here's a test which should show this up:
/format_string/test/models.py
---
from django.db import models
class Simple(models.Model):
name = models.CharField(maxlength = 50)
__test__ = {'API_TESTS':"""
# Regression test for #
# Check that the format string fix stores the correct number of %'s
>>> Simple.objects.get(pk=1).name
'a%a'
>>> Simple.objects.get(pk=2).name
'a%%a'
>>> Simple.objects.get(pk=3).name
'a%%%a'
>>> Simple.objects.get(pk=4).name
'a%%a%%a'
>>> Simple.objects.get(pk=5).name
'a%%%a%%%a'
"""
}
/format_string/test/sql/simple.sql
INSERT INTO initial_sql_formatstring_regress_simple (name) VALUES
('a%a');
INSERT INTO initial_sql_formatstring_regress_simple (name) VALUES
('a%%a');
INSERT INTO initial_sql_formatstring_regress_simple (name) VALUES
('a%%%a');
INSERT INTO initial_sql_formatstring_regress_simple (name) VALUES
('a%%a%%a');
INSERT INTO initial_sql_formatstring_regress_simple (name) VALUES
('a%%%a%%%a');
-
So - as it is, this will fail on SQLite at the .get()'s as the initial
sql import will choke when it can't work out what %a is.
Cheers,
Simon G.
[1]
http://groups.google.com/group/django-developers/browse_thread/thread/14d1bdf73085f02b/ae5dfd2b30194d4a%23ae5dfd2b30194d4a
--~--~-~--~~~---~--~~
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: RDBMS vs ODBMS
Hi off-topic'ers, Having done a decent amount of work in both an RDBMS and an ODBMS (mainly PostgreSQL and the ZODB). It has definitely been a love/hate relationship for me - when I am working in an RDBMS I yearn for a ODBMS and vice-versa. The grass is always greener ... Some Pros for an ODBMS: * Embeddable: Having your database embedded within your application can be quite useful in certain cases. Here the ZODB is a good competitor to SQLite (http://www.blueskyonmars.com/2005/06/18/zodb-vs- pysqlite-with-sqlobject/). Some portion of Plone's popularity has stemmed from it's ability to ship with a database that is managed as part of the application, as not having to pick and install an RDBMS is one less barrier to entry. * Model Inheritance: Doing model inheritance with pure objects is very easy. Jeffrey Shell has done some light comparisons of ActiveRecord versus the ZODB. http://griddlenoise.blogspot.com/ 2006/03/yay-object-database.html * Rapid Prototyping: You've got some data that you've cooked up in Python, say a tuple of dictionaries. With on object database you can just store that data as an attribute on your object - sure it's messy and your code to access the data breaks encapsulation, but sometimes it's damn nice to be able to just prototype without design tables to hold every bit of data. Also, I've seen Perl developers abuse the filesystem and treat it like a database, certainly any DBA would cringe at such practices, but damn Perl developers can bang out prototypes and do migrations insanely fast. Bjorn has pointed out many of the pros of relational database already, such as easy indexing, SQL is a widely known standard, referential integrity and strict data type enforcement. A couple additional points and corrections in defense of an object database: * You can integrate a GUI with an object database quite easily. John Barham recently gave a talk about this at the Vancouver Python Conference (http://www.vanpyz.org/conference/2006/proceedings/8rMJUi/ RestZope.html). Having your GUI talk to your application services via REST instead of doing SQL from the client GUI is going to allow you to keep all your business logic in one place, and doesn't tie you to a specific schema. * Storing pointers: In Plone this is provided at the framework level in Archetypes. You can have a ReferenceField which makes it very easy to refer to another object. Relational databases of course excel at references, and it does feel nicer to have this functionality be very robust and lower down in your framework stack. * Quering: SELECT statements and schemas make it very easy to walk up to a foreign system and easily understand it and query it. However, having to maintain indexes at the framework level means that Plone (and other CMF-based systems) allow you to query multiple content types with a single API call (something that I've not seen a RDBMS- backed framework do, although I suspect some of the Java ones might?): results = context.portal_catalog.searchResults( Type=['Document', 'File', 'Image'], Creator='kteague') * Schemas: In Plone many people use UML to diagram the schema and workflows and then simply export that into a Plone product using ArchGenXML. In Zope 3 there are Schemas and interfaces which are both quite good at building clean data models. Finally, in defence of RDBMSes it is possible to "model the dynamic operations or rules that change the state of the data in the system" as this is what stored procedures are often used for (for better or worse). Anyways, I've enjoyed (and cursed) using both relational and pure object databases as they each lead the developer to approach the problem from a different perspective and using both ultimately helps me to create better data models regardless of which system I happen to be working in at the time. - Kevin Teague --~--~-~--~~~---~--~~ 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: Automatic-manipulator, very slow..... design-decision/bug/misunderstanding?
Gábor Farkas wrote: > = > class Owner(Model): > name = CharField(maxlength=500) > thing = ForeignKey(Thing) > = > > now let's say you have a LOT of Things... like 5. > > now, when you call Owner.AddManipulator(), he's going to fetch the WHOLE > Thing-table. just to construct the AddManipulator. Change it to ForeignKey(Thing, raw_id_admin=True) and Django won't try to construct the select box. Yes, I find this quirky, too ;-) I hope that the manipulator replacement will deal with this in a more sane way. Michael --~--~-~--~~~---~--~~ 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: Automatic-manipulator, very slow..... design-decision/bug/misunderstanding?
Michael Radziej wrote: > Gábor Farkas wrote: >> = >> class Owner(Model): >> name = CharField(maxlength=500) >> thing = ForeignKey(Thing) >> = >> >> now let's say you have a LOT of Things... like 5. >> >> now, when you call Owner.AddManipulator(), he's going to fetch the WHOLE >> Thing-table. just to construct the AddManipulator. > > Change it to > ForeignKey(Thing, raw_id_admin=True) > and Django won't try to construct the select box. > > Yes, I find this quirky, too ;-) I hope that the manipulator > replacement will deal with this in a more sane way. > manymanymanymanymany thanks :) phew, and it's also documented in the model_api docs :-(. again something that i could have found. btw. it would be nice probably to mention in the docs that it also works outside of the admin. but anyway, manymany 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: Automatic-manipulator, very slow..... design-decision/bug/misunderstanding?
Gábor Farkas wrote: > now, when you call Owner.AddManipulator(), he's going to fetch the WHOLE > Thing-table. just to construct the AddManipulator. I've seen that in one of my projects and fixed it by filtering out unneeded selected with 'follow'. And it seems to me like it should be this way. --~--~-~--~~~---~--~~ 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: Automatic-manipulator, very slow..... design-decision/bug/misunderstanding?
Ivan Sagalaev wrote: > Gábor Farkas wrote: >> now, when you call Owner.AddManipulator(), he's going to fetch the WHOLE >> Thing-table. just to construct the AddManipulator. > > I've seen that in one of my projects and fixed it by filtering out > unneeded selected with 'follow'. And it seems to me like it should be > this way. > hi, is there a way to filter with the "follow"? for me it seems you can enable/disable certain fields... and that does not help with the AddManipulator, because then those fields are not even saved... 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: Django and psycopg2 problems
On Aug 31, 2006, at 12:31 AM, crankycoder wrote: > I basically need to be able to handle about a dozen languages all at > the same time. That basically means I need Unicode to work. There's > some patches in Trac that I've put up that handle all the cases that > I'm currently aware of - some of which certainly need to be cleaned > up. > > That said - the call to > "psycopg2.extensions.register_type(psycopg2.extensions.UNICODE)" is > badly needed or else I have to end up modifying all the character type > columns that go to varchar, char, or text so that they do UTF8 > encoding > on the way to becoming SQL and decoding UTF8 on the way out. > > The problem is further complicated since search queries will be made > more complicated - I'll need to modify the way the filter() method > works to encode all unicode strings to utf8 when constructing the > SELECT statement. > > I can obviously just maintain my own patchset to keep the UNICODE > setting turned on, but I don't understand what is so bad about having > it on in the first place. Essentially the problem is that this makes the psycopg2 backend behave differently from all the other backends. Thus many framework tests fail when using psycopg2, and code written for psycopg2 breaks when running with a different backend. It's totally a step backwards, but I think consistancy is more important. I'd suggest if you need the unicode behavior that you call the ``register_type`` function in your code yourself. 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 -~--~~~~--~~--~--~---
Re: Automatic-manipulator, very slow..... design-decision/bug/misunderstanding?
Gábor Farkas wrote:
> is there a way to filter with the "follow"?
> for me it seems you can enable/disable certain fields...
>
> and that does not help with the AddManipulator, because then those
> fields are not even saved...
I mean when you're creating a manipulator you can list fields that you
don't want it to touch:
manipulator = Owner.AddManipulator(follow={'thing': False})
Then it will know that it doesn't need to construct a for
Things at all.
Then of course you won't be able to save this field with the
manipulator. So if you need it then I think raw_id_admin is the way to go.
--~--~-~--~~~---~--~~
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 and psycopg2 problems
crankycoder wrote: > I really *really* need to be able to save and load unicode data in a > non-painful way. I have to support at least English, Vietnamese, Thai > and a half dozen other scripts. Why can't you use utf-8 for this? I support a two-language site (Russian, English) with psycopg1 and never had problems with it. Basically you need native unicode only if you work with individual characters in strings. --~--~-~--~~~---~--~~ 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
Am 31.08.2006 um 05:34 schrieb Adrian Holovaty: > On 8/30/06, Jay Parlar <[EMAIL PROTECTED]> wrote: >> A question then: Once the SQLAlchemy stuff is in and solid, will >> there >> be any reason *not* to use it? > > We'll decide that when we get there, but I'm inclined to answer your > question with a single word: "Simplicity." Django will continue to > work out of the box, with no dependencies. "No dependencies" is just one part of simplicity :-) Moving Django to SQLAlchemy wholesale would get rid of (or at least simplify) much of the DB code in Django. Adding SQLAlchemy support as an option is likely to increase the complexity of the code, and you basically have two different code paths to the database... patching and testing gets harder, understanding the code gets harder, writing and understanding the documentation gets harder. It's definitely a good idea to develop SQLAlchemy support as an optional alternative to the built-in ORM for now. But if the project works out, replacing the built-in DB code with SQLAlchemy is going to make a *lot* of sense IMO. Cheers, Chris -- Christopher Lenz cmlenz at gmx.de http://www.cmlenz.net/ --~--~-~--~~~---~--~~ 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: Automatic-manipulator, very slow..... design-decision/bug/misunderstanding?
On 8/31/06, Ivan Sagalaev <[EMAIL PROTECTED]> wrote:
> I mean when you're creating a manipulator you can list fields that you
> don't want it to touch:
>
> manipulator = Owner.AddManipulator(follow={'thing': False})
Thanks; I don't see that documented. Probably because manipulators
will go away...
--~--~-~--~~~---~--~~
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: Template variable evaluation for True/False ?
Hi all,
the usecase for the False/True template evaluation comes from this templatetag
here:
http://svn.sourceforge.net/viewvc/django-userlibs/trunk/libs.common/src/common/templatetags/commonmedia.py?revision=22&view=markup
function yes_no_icon_url(boolean_value)
Normally the boolean_value comes from an other object which will be evaluated
fine by the current template handling.
But then I have exactly one usecase where I don't call the function with an
object variable, instead I call it with explicit False and True. I could also
call it with 1 or 0 which would be my next step.
But {% any_tag False %} will still handled different than [% any_tag 'False'
%}. The first one will result in an error if False is not a variable-name in
the RequestContext and the second will use the string 'False'.
Regards,
Dirk
--
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Feel proud today, very very proud especially of 0.95 and MR
Hi Django developers, So for those of you that I haven't met or corresponded with, I'm the founder of Tabblo, a relatively young website for telling stories with photos, words, and highly stylized templates via a 100% web-based interface that is usable by normal humans. We've been using Django since day 1 of Tabblo and have been really happy about how much help its been. Frankly, despite having been the guy who picked it, I had originally thought that building a massively scalable site on Django was going to be a non-starter after we got past the initial phase and was just happy to start it for prototyping due to the niceties the URL mapper and the ORM provided. Boy, have you guys proven me wrong! Anyhow, this week, we completed our migration to 0.95 and magic removal which was painful but has shown us how much more great work you guys have been up to. Before the move, we were running on a hacked version of 0.91 that we had spent some cycles optimizing, mostly around ORM caching, and my big fear was that when we rolled live with MR, we were going to see all sorts of crazy slow-downs. Again, I am thrilled to have been proven wrong. I wanted to do something nice for those of you that like the kind of thing that we do at Tabblo (see here: http://app.tabblo.com/studio/view/favorites/antonio for some examples) and after talking to Adrian, we've decided that the simplest most direct thing would be to offer anyone who is so inclined a coupon for a free poster. Since we don't normally do this kind of thing, the process for getting it is going to be a little cumbersome: just send me an email (antonio at tabblo dot com) with the subject line "I am a Django developer" and I'll make sure you get the coupon within a couple of days. In the meanwhile, feel free to play with the site and take pride in what you've helped us accomplish. Standing here on the shoulders of giants, Antonio --~--~-~--~~~---~--~~ 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: Feel proud today, very very proud especially of 0.95 and MR
On 8/31/06, antonio <[EMAIL PROTECTED]> wrote: > > Anyhow, this week, we completed our migration to 0.95 and magic removal > which was painful but has shown us how much more great work you guys > have been up to. Before the move, we were running on a hacked version > of 0.91 that we had spent some cycles optimizing, mostly around ORM > caching, and my big fear was that when we rolled live with MR, we were > going to see all sorts of crazy slow-downs. Again, I am thrilled to > have been proven wrong. The site is looking fantastic, I must say. More than anything else, though, I'm thrilled that the Microsoft Clippy-esque pestering-Tabblo-face is gone. ;-) --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
name of test database
Hi, I'm checking out the changes from the last three weeks in svn ... seems like the test suite is a little bit different now ;-) I can't say much about it now other than I appreciate all the hard work by Russell, and that there's a nice test framework in place now. Only ... I find the naming of the test database a bit inconvenient. It's created as 'test_' + settings.DATABASE_NAME (unless you use sqlite). My problems with this is that it does not allow me to choose a name on my own. Now I cannot use the old 'django_test_db', since it doesn't start with 'test_'. And using the default 'test_myprojectdatabase' is not an option at all since that is used for a different purpose. So I need to contact my admins to get a new database, set up a settings file dedicated for running the django test suite, just to do that. I can work around this, sure, but I'd propose to allow to overwrite the default test database name for the test suite somehow, preferably on the command line of runtests.py. This probably also applies to using the test framework for your own application (as opposed to django's own test suite), but I haven't digged into this, yet. Cheers, Michael --~--~-~--~~~---~--~~ 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 and psycopg2 problems
Fair enough - any chance we can get that unicode branch opened up soon? vic On 8/31/06, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: > Essentially the problem is that this makes the psycopg2 backend > behave differently from all the other backends. Thus many framework > tests fail when using psycopg2, and code written for psycopg2 breaks > when running with a different backend. > > It's totally a step backwards, but I think consistancy is more > important. I'd suggest if you need the unicode behavior that you > call the ``register_type`` function in your code yourself. > > 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 -~--~~~~--~~--~--~---
Re: schema-evolution: status?
i merged with head before i checked it in. unless i really frelled up w/ svn, it should only be ~2 weeks behind. could you send just your models? (+ load script, original schema) Matthew Flanagan wrote: > Derek, > > On 31/08/06, Derek Anderson <[EMAIL PROTECTED]> wrote: >> hey matt, >> >> would you be willing to send me a copy of your app, your original >> schema, and whatever load script failed? >> >> derek > > Unfortunately I can't send you a copy of the app. However looking at > your branch it seems it may benefit from a merge from a more recent > revision of the trunk or atleast with the 0.95 release (See my message > below re: the User.is_authenticated() missing from your branch) > > Alternatively I'm on #django if we can manage to hook up there. > > matthew > >> >> Matthew Flanagan wrote: >>> 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: Integrating Django and SQLAlchemy
Adrian Holovaty wrote: > We'll decide that when we get there, but I'm inclined to answer your > question with a single word: "Simplicity." Django will continue to > work out of the box, with no dependencies. you know, I get the "no dependencies" thing, I really have a similar inclination to produce packages that arent going to create a headache about downloading other packages, getting through firewalls, and stuff like that. Even SA itself has had a little bit of criticism for this, since its "sql construction" and "orm" APIs, of which the former has no knowledge of the latter, are still all delivered in one package. but if youre talking about a "web framework" that has functionality spanning beyond a focused task, I think trying to keep it "all in one" package is going to ultimately place a burden on its structure and development. The standard way to deal with dependencies is to use package distribution tools...Ruby has gems, Perl has CPAN. Python has the cheeseshop and easy_install. Unfortunately the cheeseshop/easy_install combination remains pretty klunky, not easy to understand, and its been my experience that if you have any notions that are in disagreement with its designer (such as the PYTHONPATH variable maintaining its normal behavior), even if others agree with you, youre out of luck. So its very understandable Django wants to stay out of all that. However, Python would really benefit from cheeseshop/easy_install getting a lot more eyes and users on it, and ultimately getting the improvements needed to make it as easy to use as CPAN or better (probably better). To that end, it would be nice if Django and its very large userbase could begin to embrace it more. Guido has said he prefers django because its developers "get open source development". Well i think priority #1 of open source development is to fully embrace the platform, warts and all, and get some eyes on the issues so that they can be improved (or, introduce another distutils/cheeseshop implementation thats easier to use). The distutils-SIG list is usually very low-traffic. For something this important to Python's survival, I would think the whole community would be on that list bugreporting, patching and complaining all day until Python has the easiest to use and most world-class dependency-distribution system. Django is in a great position to crack open some of the ivory towers out there, and i think its shortsighted to ignore the tremendous usefulness (and importance) of package-based software distribution. just my rant for the day. --~--~-~--~~~---~--~~ 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
That's all well and good but there are a few projects going on that would be rendered useless if Django eventually did adopt SQLAlchemy, including the Schema Evolution and the multiple DB branch. Also this puts into question the philosophy of the full-stack, and if you really want to be tied to SQLAlchemy... Both questions that need to be answered later on down the road, I'm sure, but still something to think about. On 8/30/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > > On 8/30/06, Jay Parlar <[EMAIL PROTECTED]> wrote: > > A question then: Once the SQLAlchemy stuff is in and solid, will there > > be any reason *not* to use it? > > We'll decide that when we get there, but I'm inclined to answer your > question with a single word: "Simplicity." Django will continue to > work out of the box, with no dependencies. > > 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: Row level permission problem in admin for inline edited objects
It would work, but there it's not very flexible. The current show_all_rows setting uses the change permission to determine if the object should be shown on the change list. Which makes sense, since the objects listed on the change list are those the user is able to edit. For a related object in a select field it might require a bit more flexibility. For example, if we had a CMS where users can add articles, and there was a category model related to the article model. The administrator might create a list of categories that he does not want to be modified by other users. But he does want it set up so only certain users can post to certain categories and can not modify those given categories. It would work where the user has change permission or view permission. Maybe it's an addition that would only be used in a few extreme cases, if so there isn't much point in having it. For now, I'm working on modifying the code to use hte change permisison, but I'll allow it open to be extended to include a view permission depending on the feedback. Cheers, Chris --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Filters no longer parsed for unresolved variables
Changeset [3268] made the following change for the resolve method in django/template/__init__.py: -obj = settings.TEMPLATE_STRING_IF_INVALID +if ignore_failures: +return None +else: +return settings.TEMPLATE_STRING_IF_INVALID Because the TEMPLATE_STRING_IF_INVALID is returned now rather than being set in obj (which is then passed to any filters), the filters are not parsed on an unresolved variable which changes the behaviour of the default and default_if_none filters. I believe the last line of that patch should have been: +obj = settings.TEMPLATE_STRING_IF_INVALID but I just wanted to check that the functionality change isn't intended first. --~--~-~--~~~---~--~~ 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: (OT) Feel proud today, very very proud especially of 0.95 and MR
On Thursday 31 August 2006 17:28, antonio wrote: > cumbersome: just send me an email (antonio at tabblo dot com) I just discovered a cool thing: I copied and pasted 'antonio at tabblo dot com' into the 'To' field in a new e-mail in KMail, and it automatically translated the 'at' and the 'dot' for me (which I was about to do myself), leaving the correct e-mail address! Wow! (Sorry, I don't get out much) Luke -- "Pessimism: Every dark cloud has a silver lining, but lightning kills hundreds of people each year trying to find it." (despair.com) 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: Filters no longer parsed for unresolved variables
Guess I should just make a ticket anyway: http://code.djangoproject.com/ticket/2637 --~--~-~--~~~---~--~~ 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: XSS comments from PHP Creator
Ian Holsman wrote: > On 21/08/2006, at 9:24 PM, [EMAIL PROTECTED] wrote: > > You deny everything by default, and have holes added when you need them. > and when you poke a hole you have a reference to why it is required > (ie what module needs a particular variable unfiltered) > > Things which you don't know will hurt you unfortunately. and by > using deny by default with a big sledgehammer will > stop a lot of these things before they even touch your code. > > doing it the other way requires a conscious effort to maintain the > firewall, and you won't know when you are failing. > Hmm, didn't see the reply to this until now. Anyway - yes, you're right. But I think there is a tendency to go overboard with things like mod_security. For example, you can download huge lists of mod_sec rules at places like gotroot.com, which have some very broad spectrum anti SQL-injection, XSS etc rules e.g. last I looked at them there was a rule to deny all POSTs with various SQL keywords ( select, insert, drop, etc ). The chances of false positives are very high with things like this. I guess my major issue here is that the webserver should not be protecting crappy applications from themselves. Mod_security and similar should not be relied on. The application needs to do the relevant security. --Simon --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
POST data is corrupted, or is it really?
Hi,
I am new to Django and Python, and web programming in general.
I have a very simple form and the dictionary request.POST does not
store the information correctly. I may be doing something wrong, so
please help me.
urls.py:
urlpatterns += patterns( (r'^photo/info/$', 'views.info'), )
form.html: (relavant contents )
Tags:
Title:
Caption:
some_text
views.py:
def info(request):
if request.method == 'POST':
print request.POST['tag_str']
print request.POST['title_str']
return HttpResponse('testing')
After the form is rendered, I enter the following:
For Tags : tag1, tag2
For Title: This is the title
For Caption: Some random paragraph
Now here is the problem: print request.POST['tag_str'] in function
views.info prints the following:
tag1, tag2 title_str=This is the title caption_str=Some random
paragraph
and print request.POST['title_str'] returns error because key
'title_str' is not found.
What am I doing wrong? Why are the keys and their respective values in
tag_str?
Thanks.
Regards,
Bala.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Fwd: [CAR] Error (EXTERNAL IP): /aggy/filter/
hmm.. anyone else ever see google misbehave?
check out the weird dates google is putting in it's parameter lists.
car-chatter.com 66.249.65.235 - - [31/Aug/2006:11:43:57 +] "GET /
aggy/filter/?
date_modified__day=17&date_modified__month=7&ot=asc&date_modified__year=
2006&o=1 HTTP/1.1" 200 10673 "-" "Mozilla/5.0 (compatible; Googlebot/
2.1; +http://www.google.com/bot.html)"
car-chatter.com 66.249.65.235 - - [31/Aug/2006:14:49:58 +] "GET /
aggy/filter/?date_modified__day=z%7Czzz%7F&date_modified__month=~%
7F~&date_modified__year=%7Cz%7Cw%7F%7B~ww%7D%7Fu&o=%7D%7F%7F&ot=y%
7Fyz HTTP/1.1" 500 5400 "-" "Mozilla/5.0 (compatible; Googlebot/2.1;
+http://www.google.com/bot.html)"
car-chatter.com 66.249.65.235 - - [31/Aug/2006:14:50:09 +] "GET /
aggy/filter/?date_modified__day=~%7B%7Dz%7F%7F&date_modified__month=%
7F%7F%7D&date_modified__year=%7Cvywu%7Dt%7Dz%7Dyw&o=%7D~%7F&ot=wz%
7Dxt HTTP/1.1" 500 5400 "-" "Mozilla/5.0 (compatible; Googlebot/2.1;
+http://www.google.com/bot.html)"
car-chatter.com 66.249.65.235 - - [31/Aug/2006:14:50:20 +] "GET /
aggy/filter/?date_modified__day=%7Cz~%7B~%7F&date_modified__month=%7F%
7D%7F&date_modified__year=v~ztzzwt&o=%7F~%7D&ot=%7Dxx~~%7Bxwx
HTTP/1.1" 500 5400 "-" "Mozilla/5.0 (compatible; Googlebot/2.1;
+http://www.google.com/bot.html)"
car-chatter.com 66.249.65.235 - - [31/Aug/2006:14:50:33 +] "GET /
aggy/filter/?date_modified__day=%7Fz%7C%7F%7D%7B&date_modified__month=
%7D~~&date_modified__year=~x~tyu%7B%7Duz%7D~&o=%7D%7F%7D&ot=%7Dxy%
HTTP/1.1" 500 5400 "-" "Mozilla/5.0 (compatible; Googlebot/2.1;
+http://www.google.com/bot.html)"
car-chatter.com 66.249.65.235 - - [31/Aug/2006:14:50:44 +] "GET /
aggy/filter/?date_modified__day=%7F~%7F%7D%7C~&date_modified__month=%
7F%7D%7F&date_modified__year=%7Ftzzyx%7Dwww%7Du&o=~%7D%7D&ot=wvuxt~vz
% HTTP/1.1" 500 5400 "-" "Mozilla/5.0 (compatible; Googlebot/2.1;
+http://www.google.com/bot.html)"
car-chatter.com 66.249.65.235 - - [31/Aug/2006:14:50:54 +] "GET /
aggy/filter/?
date_modified__day=14&date_modified__month=7&date_modified__year=2006&o=
3&ot=desc HTTP/1.1" 200 10663 "-" "Mozilla/5.0 (compatible; Googlebot/
2.1; +http://www.google.com/bot.html)"
Begin forwarded message:
> From: [EMAIL PROTECTED]
> Date: 31 August 2006 2:51:39 PM
> To: [EMAIL PROTECTED]
> Subject: [CAR] Error (EXTERNAL IP): /aggy/filter/
>
> Traceback (most recent call last):
>
>
> File "/home2/zilbo/webapps/django/zilbo/common/filter/
> templatetags/filter_list.py", line 206, in date_hierarchy
> day = datetime.date(int(year_lookup), int(month_lookup), int
> (day_lookup))
>
> ValueError: invalid literal for int(): v~ztzzwt
>
>
> path:/aggy/filter/,
> GET: 'date_modified__month': ['\x7f}\x7f'], 'ot': ['}xx~~{xwx'],
> 'date_modified__year': ['v~ztzzwt'], 'o': ['\x7f~}']}>,
> POST:,
> COOKIES:{},
> META:{'AUTH_TYPE': None,
> 'CONTENT_LENGTH': 0L,
> 'CONTENT_TYPE': None,
> 'GATEWAY_INTERFACE': 'CGI/1.1',
> 'HTTP_ACCEPT': '*/*',
> 'HTTP_ACCEPT_ENCODING': 'gzip',
> 'HTTP_FROM': 'googlebot(at)googlebot.com',
> 'HTTP_HOST': 'car-chatter.com',
>
> 'PATH_INFO': '/filter/',
> 'PATH_TRANSLATED': None,
> 'QUERY_STRING': 'date_modified__day=%7Cz~%7B~%
> 7F&date_modified__month=%7F%7D%
> 7F&date_modified__year=v~ztzzwt&o=%7F~%7D&ot=%7Dxx~~%7Bxwx',
> 'REMOTE_ADDR': '66.249.65.235',
> 'REMOTE_HOST': None,
> 'REMOTE_IDENT': None,
> 'REMOTE_USER': None,
> 'REQUEST_METHOD': 'GET',
> 'SCRIPT_NAME': None,
> 'SERVER_NAME': 'car-chatter.com',
> 'SERVER_PORT': 0,
> 'SERVER_PROTOCOL': 'HTTP/1.1',
> 'SERVER_SOFTWARE': 'mod_python'}>
--
Ian Holsman
[EMAIL PROTECTED]
http://zyons.com/ build a Community with 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: XSS comments from PHP Creator
On 8/22/06, Ahmad Alhashemi <[EMAIL PROTECTED]> wrote: > But if you keep poking holes in all the wrong places, then it is not > the frameworks fault. > > Autoescaping might be a nice DRY feature, but I don't think it has > anything to do with being secure by default. Usable security is about making it easier to do the things that make or keep you secure and making it less easy to do things that are dangerous or insecure. Everybody using dj templates is putting context into them all the time; most of the time it's fine. You're trained into doing something by rote and sometimes it's wrong. Interaction with applications (even text editors and codelibs) wears grooves in the judgement of people. Escape by default is the Right way. I'd much rather see a double-escaped whoopsie than have my cookies stolen. --~--~-~--~~~---~--~~ 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: Fwd: [CAR] Error (EXTERNAL IP): /aggy/filter/
That's really weird. I've never seen that before - isn't 7F a control character? 7B's "}" so it's not like it's trying to guess sensible URLs. The IP looks right for google, but given that control character usage, I'd say it looks fairly dodgy. --Simon --~--~-~--~~~---~--~~ 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: Automatic-manipulator, very slow..... design-decision/bug/misunderstanding?
Jeremy Dunck wrote:
> On 8/31/06, Ivan Sagalaev <[EMAIL PROTECTED]> wrote:
> > I mean when you're creating a manipulator you can list fields that you
> > don't want it to touch:
> >
> > manipulator = Owner.AddManipulator(follow={'thing': False})
>
> Thanks; I don't see that documented. Probably because manipulators
> will go away...
I'm not sure if it's up to date, but there is mention of the follow
here:
http://code.djangoproject.com/wiki/NewAdminChanges#Manipulatorsandinlineediting
--~--~-~--~~~---~--~~
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
Adrian Holovaty wrote: > Thanks for bringing this up, Gary. The get_and_delete_messages() thing > has always bothered me -- if it's activated, we do it for every > request. I suppose we could make the 'messages' part of the context > processor lazy, so that it would only call get_and_delete_messages() > if that variable were accessed in the template... Thoughts? We could make the messages part lazy, but we also don't want to have to pass it request.user because that defeats the purpose of LazyUser. What if we gave the LazyUser class a lazy "messages" property and dont pass a "messages" context variable in the context processor. The templates would instead access messages through the "user" context variable. Of course, this would make the templates backwards incompatible. As far as Django code, the messages variable seems to get used only in contrib/admin/templates/admin/base.html. I think it would be a good idea to add some re-usable Lazy object class to Django, something like this: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/363602 This lazy loading stuff is a common scenario. --~--~-~--~~~---~--~~ 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: schema-evolution: status?
On 01/09/06, Derek Anderson <[EMAIL PROTECTED]> wrote: > > i merged with head before i checked it in. unless i really frelled up > w/ svn, it should only be ~2 weeks behind. I think you may have "frelled up". Your branch was created on 07/11/06 and from the revision log [1] it does appear that you've merged any changes from the trunk in since then. In fact if I do a merge from trunk at the last revision (r3644) before your checked in your schema-evolution code it shows a bunch of changes: $ cd ~/src $ svn co http://code.djangoproject.com/svn/django/branches/schema-evolution $ cd schema-evolution $ svn merge --dry-run -r3332:3644 http://code.djangoproject.com/svn/django/trunk Udjango/dispatch/license.txt Udjango/dispatch/saferef.py Udjango/dispatch/errors.py Udjango/dispatch/robust.py Udjango/dispatch/robustapply.py Udjango/dispatch/dispatcher.py Udjango/http/__init__.py Udjango/contrib/auth/backends.py Udjango/contrib/auth/views.py Udjango/contrib/auth/__init__.py Udjango/contrib/auth/models.py Udjango/contrib/auth/decorators.py Udjango/contrib/auth/forms.py Udjango/contrib/syndication/feeds.py Udjango/contrib/comments/models.py Udjango/contrib/comments/templatetags/comments.py Udjango/contrib/comments/feeds.py Udjango/contrib/comments/views/karma.py Udjango/contrib/comments/views/comments.py Udjango/contrib/comments/templates/comments/form.html Udjango/contrib/flatpages/views.py Udjango/contrib/flatpages/README.TXT Udjango/contrib/sessions/middleware.py Udjango/contrib/sessions/models.py Udjango/contrib/admin/media/css/layout.css Udjango/contrib/admin/media/css/global.css Udjango/contrib/admin/media/css/rtl.css Udjango/contrib/admin/media/css/changelists.css Udjango/contrib/admin/media/css/forms.css Udjango/contrib/admin/media/js/admin/RelatedObjectLookups.js Udjango/contrib/admin/media/js/admin/CollapsedFieldsets.js Udjango/contrib/admin/media/js/admin/DateTimeShortcuts.js Udjango/contrib/admin/utils.py Udjango/contrib/admin/filterspecs.py Udjango/contrib/admin/templatetags/admin_modify.py Udjango/contrib/admin/templatetags/admin_list.py Udjango/contrib/admin/urls.py Udjango/contrib/admin/views/template.py Adjango/contrib/admin/views/auth.py Udjango/contrib/admin/views/main.py ...etc etc [1] http://code.djangoproject.com/log/django/branches/schema-evolution > > could you send just your models? (+ load script, original schema) > Sorry, as I stated before I can't shared the code as it is for an internal project for my employer. I'll just say that I haven't actually try to "evolve" any schema yet, I'm just trying to get my project up and running on your branch. regards matthew > > Matthew Flanagan wrote: > > Derek, > > > > On 31/08/06, Derek Anderson <[EMAIL PROTECTED]> wrote: > >> hey matt, > >> > >> would you be willing to send me a copy of your app, your original > >> schema, and whatever load script failed? > >> > >> derek > > > > Unfortunately I can't send you a copy of the app. However looking at > > your branch it seems it may benefit from a merge from a more recent > > revision of the trunk or atleast with the 0.95 release (See my message > > below re: the User.is_authenticated() missing from your branch) > > > > Alternatively I'm on #django if we can manage to hook up there. > > > > matthew > > > >> > >> Matthew Flanagan wrote: > >>> 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 -~--~~~~--~~--~--~---
