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. Indeed great news!! At work i am trying to build the Django ORM on the top of SQLAlchemy core. I've tried on the top of the ORM but it was overkill, but i could had done something wrong. I was getting about ~10 request per second oposed to ~50 request per second with firebird. Are you planning to build the integration on the top of the SQLAlchemy ORM? --~--~-~--~~~---~--~~ 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: Support for Native XML Database (NXD)
My conclusion is that for storing XML data would be usefull ut using a ODBMS based on the ODMG 3.0 specification that incorporates advances in object database technology (e.g., replication), data management (e.g., spatial indexing), and data formats (e.g., XML) and to include new features into these standards that support domains where object databases are being adopted (e.g., real-time systems). http://en.wikipedia.org/wiki/Object_database Althought there is only one free ODBMS, ozone, that provides a ODMG 3.0 interface but it has been built in java http://www.ozone-db.org/frames/home/what.html --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
RDBMS vs ODBMS
I have seen that for web applications is best far using a ODBMS: 1- Objects in an OODBMS can store an arbitrary number of atomic types as well as other objects. The fact that an OODBMS is better suited to handling complex,interrelated data than an RDBMS means that an OODBMS can outperform an RDBMS by ten to a thousand times depending on the complexity of the data being handled. 2- Data in the real world is usually has hierarchical characteristics. The ever popular Employee example used in most RDBMS texts is easier to describe in an OODBMS than in an RDBMS. 3- A query language is not necessary for accessing data from an OODBMS unlike an RDBMS since interaction with the database is done by transparently accessing objects. It is still possible to use queries in an OODBMS however. 4- In a typical application that uses an object oriented programming language and an RDBMS, a signifcant amount of time is usually spent mapping tables to objects and back. This "impedance mismatch" is completely avoided when using an OODBMS. 5- The user of an RDBMS has to worry about uniquely identifying tuples by their values and making sure that no two tuples have the same primary key values to avoid error conditions. 6- With an RDBMS it is not possible to model the dynamic operations or rules that change the state of the data in the system because this is beyond the scope of the database. With an OODBMS there is no disconnect between the database model and the application model because the entities are just other objects in the system. http://www.kuro5hin.org/?op=displaystory;sid=2001/5/3/32853/11281 http://www.odbms.org/introduction_whenODBMS.html http://en.wikipedia.org/wiki/Object_database --~--~-~--~~~---~--~~ 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
yes.. what exactly are you proposing here? with a OODBMS you shouldn't need any of the ORM functionality.. you should be able to just use the other sections without much worry i would suspect. regards Ian On 30/08/2006, at 8:10 PM, GinTon wrote: > > I have seen that for web applications is best far using a ODBMS: > > 1- Objects in an OODBMS can store an arbitrary number of atomic types > as well as other objects. The fact that an OODBMS is better suited to > handling complex,interrelated data than an RDBMS means that an OODBMS > can outperform an RDBMS by ten to a thousand times depending on the > complexity of the data being handled. > > 2- Data in the real world is usually has hierarchical characteristics. > The ever popular Employee example used in most RDBMS texts is > easier to > describe in an OODBMS than in an RDBMS. > > 3- A query language is not necessary for accessing data from an OODBMS > unlike an RDBMS since interaction with the database is done by > transparently accessing objects. It is still possible to use > queries in > an OODBMS however. > > 4- In a typical application that uses an object oriented programming > language and an RDBMS, a signifcant amount of time is usually spent > mapping tables to objects and back. This "impedance mismatch" is > completely avoided when using an OODBMS. > > 5- The user of an RDBMS has to worry about uniquely identifying tuples > by their values and making sure that no two tuples have the same > primary key values to avoid error conditions. > > 6- With an RDBMS it is not possible to model the dynamic operations or > rules that change the state of the data in the system because this is > beyond the scope of the database. With an OODBMS there is no > disconnect > between the database model and the application model because the > entities are just other objects in the system. > > > http://www.kuro5hin.org/?op=displaystory;sid=2001/5/3/32853/11281 > http://www.odbms.org/introduction_whenODBMS.html > http://en.wikipedia.org/wiki/Object_database > > > > -- Ian Holsman [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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, gabor <[EMAIL PROTECTED]> wrote: > > 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? Not yet -- I don't have anything yet. It's only been a few days since I even started thinking about it when Adrian contacted me. Once I have the ideas fleshed out a little bit, I'll be able to show some examples. > 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... Basically, your code won't change much, and you'll use the Django API as-is, except inheriting from django.contrib.sqlalchemy.db.models instead of django.db.models. Then when you need to get at the SQLAlchemy Table object, you'd do something like Story._sa_table.some_method(). At least that's the current plan. It may change as I implement this. > or ...well..maybe it's too early to ask questions like this :) > > thanks, > gabor It's never too early to ask questions. Sometimes it's too early to get detailed answers, though. :-) -- 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: RDBMS vs ODBMS
Ian Holsman wrote: > yes.. > what exactly are you proposing here? > > with a OODBMS you shouldn't need any of the ORM functionality.. you > should be able to just use the other sections without > much worry i would suspect. > I wanted to know your opinions. Since of my view point I think that the web frameworks with ODBMS will be the next big step. The problem is that today it is not a true option since that it only exists a free ODBMS based on the ODMG 3.0 specification, ozone, that has been built in java. http://en.wikipedia.org/wiki/Object_database http://www.ozone-db.org/frames/home/what.html As it is said in 4 point, It's true that using a ODBMS would not be necessary the ORM functionality, another more advantage. --~--~-~--~~~---~--~~ 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/30/06, JP <[EMAIL PROTECTED]> wrote: > > 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. SQLAlchemy already has a DynamicMetaData object that can connect model objects to different database engines; I currently plan to use that. I'll definitely take a look at the multi-db code and would welcome any help you might want to offer. Whether the multi-db branch becomes irrelevant or not will entirely depend on adoption, I think. Maybe most people won't want to use the SQLAlchemy branch, and it will wither and die from lack of interest, while the multi-db branch will be widely used. Or maybe people will jump on the SQLAlchemy branch like it's the best thing since sliced bread, and it will become the default. It's far too early to tell. Basically, don't stop work on multi-db just because I'm starting this branch. I might hit a brick wall and not be able to complete it, or I might get hit by a bus tomorrow, or whatever -- you never know what's going to happen. I'd welcome any ideas or code you'd like to share, though. > 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. Right now, I plan to use ActiveMapper -- why re-invent the wheel? I'd be happy to look at your code, though. I like "borrowing" from other people's work whenever I can, it means less work for me. :-) And that's what open-source development is all about, isn't it? -- 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: Integrating Django and SQLAlchemy
On 8/30/06, David Elias <[EMAIL PROTECTED]> wrote: > > > 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. > > Indeed great news!! > > At work i am trying to build the Django ORM on the top of SQLAlchemy > core. I've tried on the top of the ORM but it was overkill, but i could > had done something wrong. I was getting about ~10 request per second > oposed to ~50 request per second with firebird. > > Are you planning to build the integration on the top of the SQLAlchemy > ORM? If I understand your question correctly, the answer is yes. Here's how I plan to have it work: User models | v Django DB | <-- This is the API I'll be building v SQLAlchemy ORM | v Database (Postgres, SQLite, Firebird...) The plan is for the user model to Django DB API won't change at all (if possible), and I won't be touching the SQLAlchemy-to-database API either. I'll be building that connector in the middle. -- 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: Django Test framework commits (r3658-r3661)
Malcolm,
Hmm... ok I was running 3.1.3 on OSX (installed via darwinports). I've
upgraded to 3.3.7. Also upgraded pysqlite to the latest in darwinports
(2.0.5). But the tests fail for many_to_one and many_to_many whenever
.count() is used with .distinct().
Specifically:
(many_to_one:)
Reporter.objects.filter(article__headline__startswith='This').distinct().count()
(many_to_many:)
Article.objects.filter(publications__title__startswith="Science").distinct().count()
So I went and had a play with this, and the query that's generated by
Django looks something like:
SELECT COUNT(DISTINCT("tablename"."id")) FROM "tablename"
...which works fine when cut and pasted into SQlite. Tracing it up the
stack, Django's not messing this up, it looks like pysqlite is.
Next step - manually upgraded to pysqlite 2.3.2 (the latest), and still
doesn't work. It's definitely an issue with pysqlite, & I've submitted
a ticket [1]
[1] http://initd.org/tracker/pysqlite/ticket/173
--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: Integrating Django and SQLAlchemy
On 8/30/06, Robin Munn <[EMAIL PROTECTED]> wrote: > Right now, I plan to use ActiveMapper -- why re-invent the wheel? I'd > be happy to look at your code, though. I like "borrowing" from other > people's work whenever I can, it means less work for me. :-) And > that's what open-source development is all about, isn't it? This is probably something I should submit a patch for in ActiveMapper itself, but the biggest problem with ActiveMapper is that you can't get at the primaryjoin and secondaryjoin attributes to do the more involved mapping. As a result, I normally just do assign_mapper throughout, as ActiveMapper and non-ActiveMapper models don't work well together. AM itself is like 200 lines of code on top of the SA core. ;] --~--~-~--~~~---~--~~ 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?
I've attached my patch with the ticket. After patching both of the
following work:
# return a string , as before
@register.simple_tag
def func(...):
...
return 'a string'
# return a dict, items of the dict will be set to context
@register.simple_tag
def func(...):
...
return {'key' : value, ... }
--~--~-~--~~~---~--~~
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
On 8/30/06, GinTon <[EMAIL PROTECTED]> wrote: > I wanted to know your opinions. Since of my view point I think that the > web frameworks with ODBMS will be the next big step. I prefer an RDBMS because I tend to integrate with other projects/languages at the RDBMS level. The other advantage is that the RDBMS are much better tested because they're in wider use. I can usually handle the impedance mismatch, even though ORM is the Vietnam of Computer Science[1]. [1] http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx --~--~-~--~~~---~--~~ 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?
hey matt, would you be willing to send me a copy of your app, your original schema, and whatever load script failed? derek 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 -~--~~~~--~~--~--~---
Google Sitemaps
Just wanted to draw some attention to http://code.djangoproject.com/ticket/2628 - it's a contrib app I've written to automatically generate sitemap.xml files for Google. I've also written about it here: http://theidioteque.net/blog/2006/08/29/google-sitemaps/ Not sure if people will use it, but suggestions and feedback are always welcome! Dan --~--~-~--~~~---~--~~ 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: Google Sitemaps
On Aug 30, 2006, at 11:51 AM, Dan Watson wrote: > Just wanted to draw some attention to > http://code.djangoproject.com/ticket/2628 - it's a contrib app I've > written to automatically generate sitemap.xml files for Google. I've > also written about it here: > http://theidioteque.net/blog/2006/08/29/google-sitemaps/ Great stuff, Dan! My only quibble is the recommendation in the docs to call ``ping_google()`` from the ``save()`` method. I think the idea of setting off a HTTP request from within a ``save()`` method isn't such a grand idea; network latency could cause the save to take too long, or the request could raise an exception causing the object not to get saved... I'm not sure about what would be better, but it does rub me the wrong way. Regardless, I'd be all for including this in django.contrib... what do other people think? 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: multiple authentication and session keys
On 8/29/06, Gary Wilson <[EMAIL PROTECTED]> wrote: > 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. 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? 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: Google Sitemaps
Jacob Kaplan-Moss wrote: > On Aug 30, 2006, at 11:51 AM, Dan Watson wrote: > > Just wanted to draw some attention to > > http://code.djangoproject.com/ticket/2628 - it's a contrib app I've > > written to automatically generate sitemap.xml files for Google. I've > > also written about it here: > > http://theidioteque.net/blog/2006/08/29/google-sitemaps/ > > Great stuff, Dan! > > My only quibble is the recommendation in the docs to call > ``ping_google()`` from the ``save()`` method. I think the idea of > setting off a HTTP request from within a ``save()`` method isn't such > a grand idea; network latency could cause the save to take too long, > or the request could raise an exception causing the object not to get > saved... I'm not sure about what would be better, but it does rub me > the wrong way. Yeah, I wasn't too concerned about the latency, since a save operation taking a little longer isn't so bad compared to a read operation. My concern would be more along the lines of sending a lot of pings unnecessarily. A smarter approach for most sites would be to call it daily (or at some interval) from a cron job. I'm fine with with taking that piece out of the documentation, though. Dan --~--~-~--~~~---~--~~ 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
Hi Chris, why not use the existing show_all_rows admin setting? When logged in users with restricted permissions access the respective admin change list page for 'Object' objects they don't get to see rows they do not have permission to change if show_all_rows=false is set anyway. So if they access the change page for 'ObjectProperty' objects it would seem intuitive to not show them 'Object' objects in the select they would not see in the 'Object' change list page either. littleswo --~--~-~--~~~---~--~~ 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
> I prefer an RDBMS because I tend to integrate with other > projects/languages at the RDBMS level. The other advantage is that the > RDBMS are much better tested because they're in wider use. I second carls opinion. With RDBMS you easily create a gui app that connects to the db used by some web apps. and best thing GUI is completly independent of web app. I mean I can have my web app in python and my gui in c++ or vice versa. More over OODBMS's are way too language specific due to the differences in object models in various languages. But if you know of an OODBMS that understands the object model of python, java, .net, c++, ruby, perl, php etc. and translates between them transparently, I will use that. --~--~-~--~~~---~--~~ 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: Google Sitemaps
Hi, Dan. On 8/30/06, Dan Watson <[EMAIL PROTECTED]> wrote: > Not sure if people will use it, but suggestions and feedback are always > welcome! I had to do a sitemap generator for a client from work recently -- my code is pre-mr due to older version of Django we're on. One of the problems I had was that I needed to specify priority on a fairly granular level, not to mention quite a large number of URLs. I only glanced at your code, so my appologies if your docs cover this, but do you have any means for configuring priority per URL? For example, say one blog entry in your blog sitemap is important to you, but unindexed or misrepresented in Google's index, and you want to specify a 0.8 priority for it, but 0.5 for other blog urls. Porbably not something that affects a lot of folks, but just something to consider from a real world use case. Cheers, deryck -- Deryck Hodgehttp://www.devurandom.org/ Web Developer, Naples News http://www.naplesnews.com/ Samba Team http://www.samba.org/ --~--~-~--~~~---~--~~ 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: Re: Google Sitemaps
On 8/30/06, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: > My only quibble is the recommendation in the docs to call > ``ping_google()`` from the ``save()`` method. I think the idea of > setting off a HTTP request from within a ``save()`` method isn't such > a grand idea; network latency could cause the save to take too long, > or the request could raise an exception causing the object not to get > saved... I'm not sure about what would be better, but it does rub me > the wrong way. OT: for some purposes, I think this is probably the best solution. For example, on my blog I have the save() method for links post them to del.icio.us (with some fairly ham-handed exception handling to make sure it doesn't break anything). I suppose it would be possible to hook onto this with the dispatcher, but I'm not sure whether that feels intuitive or not. -- "May the forces of evil become confused on the way to your house." -- George Carlin --~--~-~--~~~---~--~~ 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
Karl Guertin wrote: > This is probably something I should submit a patch for in ActiveMapper > itself, but the biggest problem with ActiveMapper is that you can't > get at the primaryjoin and secondaryjoin attributes to do the more > involved mapping. As a result, I normally just do assign_mapper > throughout, as ActiveMapper and non-ActiveMapper models don't work > well together. AM itself is like 200 lines of code on top of the SA > core. ;] starting to get off topic here, while I can believe that mixing AM and non-AM models probably have glitches (since nobody has tried it out too much), there shouldnt be anything deeply broken with mixing the two; an AM object is basically a regular mapped object (via assign_mapper) with just a slightly weird way of setting up its Table/Mapper/relationships. While i dont have the cycles to address it single-handedly, Im sure the issues could be resolved if we come up with some decent test cases as well as some consistent and documented ways to get at the Table/Mapper of an AM object. We really should have a real doc for ActiveMapper. --~--~-~--~~~---~--~~ 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: Google Sitemaps
Deryck Hodge wrote: > Hi, Dan. > > On 8/30/06, Dan Watson <[EMAIL PROTECTED]> wrote: > > Not sure if people will use it, but suggestions and feedback are always > > welcome! > > I had to do a sitemap generator for a client from work recently -- my > code is pre-mr due to older version of Django we're on. One of the > problems I had was that I needed to specify priority on a fairly > granular level, not to mention quite a large number of URLs. I only > glanced at your code, so my appologies if your docs cover this, but do > you have any means for configuring priority per URL? For example, say > one blog entry in your blog sitemap is important to you, but unindexed > or misrepresented in Google's index, and you want to specify a 0.8 > priority for it, but 0.5 for other blog urls. Sure, this works just like syndication (or the example in my docs for the lastmod method). items() returns a list of objects (blog entries in your case), and if a priority() method exists in your Sitemap, it is called with each object. Chances are, your BlogSitemap class would look something like this: class BlogSitemap (Sitemap): changefreq = "monthly" def items( self ): return Entry.objects.all() def lastmod( self, obj ): return obj.pub_date def priority( self, obj ): return obj.priority Dan > Porbably not something that affects a lot of folks, but just something > to consider from a real world use case. > Cheers, > deryck > > -- > Deryck Hodgehttp://www.devurandom.org/ > Web Developer, Naples News http://www.naplesnews.com/ > Samba Team http://www.samba.org/ --~--~-~--~~~---~--~~ 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: Google Sitemaps
On 8/30/06, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: My only quibble is the recommendation in the docs to call``ping_google()`` from the ``save()`` method. I think the idea ofsetting off a HTTP request from within a ``save()`` method isn't sucha grand idea; network latency could cause the save to take too long, or the request could raise an exception causing the object not to getsaved... I'm not sure about what would be better, but it does rub methe wrong way.What about using signals? The ping_google() call could be activated by hooking in to the post_save() signal. David Blewett --~--~-~--~~~---~--~~ 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: Google Sitemaps
I've installed it and it's very nice. I've moved "sitemap" to contrib - is it ok? :) because there is one minor problem is with sitemap.xml - it try to load it from: Django tried loading these templates, in this order: Using loader django.template.loaders.filesystem.load_template_source: templates/sitemap.xml (File does not exist) Using loader django.template.loaders.app_directories.load_template_source: /usr/lib/python2.4/site-packages/Django-0.95-py2.4.egg/django/contrib/admin/templates/sitemap.xml (File does not exist) when i put sitemap.xml in my templates dir (templates/) it works nicely :) PS. how can i combine two querysets and set different priority for them? :) --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Template variable evaluation for True/False ?
Hi all, why was False/True evaluation in http://code.djangoproject.com/changeset/3680 reverted? The committer russelm said: Template variable evalution should follow Python norms. What would be more Python norms for true and false as True and 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 -~--~~~~--~~--~--~---
Re: Google Sitemaps
[EMAIL PROTECTED] wrote: > I've installed it and it's very nice. I've moved "sitemap" to contrib - > is it ok? :) because there is one minor problem is with sitemap.xml - > it try to load it from: > > Django tried loading these templates, in this order: > Using loader django.template.loaders.filesystem.load_template_source: > templates/sitemap.xml (File does not exist) > Using loader > django.template.loaders.app_directories.load_template_source: > /usr/lib/python2.4/site-packages/Django-0.95-py2.4.egg/django/contrib/admin/templates/sitemap.xml > (File does not exist) > > when i put sitemap.xml in my templates dir (templates/) it works nicely > :) I guess it's probably worth mentioning you need to put django.contrib.sitemap in your INSTALLED_APPS, and you need django.template.loaders.app_directories.load_template_source in your TEMPLATE_LOADERS for it to work out of the box. Or you can just do what you did, and copy the templates and skip the other two steps :-) > PS. how can i combine two querysets and set different priority for > them? :) items() just needs to return a list, so you could just build a list by evaluating both querysets and concatenating them. Then in priority(), you could check to see the type of the passed-in object and return a priority accordingly. A cleaner approach, however, would just to just create two Sitemap subclasses, each with a "priority" class attribute. I suppose I could also update GenericSitemap to take a default_priority (and a default_* for that matter)... what do people think about that? Dan --~--~-~--~~~---~--~~ 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 ?
On 8/30/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > The committer russelm said: Template variable evalution should follow Python > norms. As I understand it, the distinction is between the string 'False' and the boolean False. In other words, if you pop open a Python shell and do this: >>> 'False' is False False You find that they're not the same -- 'False' is a non-empty string of characters and in boolean comparisons evaluates True. False (without quotes) is a constant which always evaluates False. -- "May the forces of evil become confused on the way to your house." -- George Carlin --~--~-~--~~~---~--~~ 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
Op zo, 20-08-2006 te 12:14 +0300, schreef Ahmad Alhashemi: > Note that you can do this outside of Django. I think that there is > something like this for apache called mod_security. It works > regardless of the scripting language/framework you are using. I wonder if you know any *sensible* rules set for mod_security then? -- Jan Claeys --~--~-~--~~~---~--~~ 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 James,
James Bennett schrieb:
> On 8/30/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>> The committer russelm said: Template variable evalution should follow Python
>> norms.
>
> As I understand it, the distinction is between the string 'False' and
> the boolean False.
>
> In other words, if you pop open a Python shell and do this:
>
'False' is False
> False
>
> You find that they're not the same -- 'False' is a non-empty string of
> characters and in boolean comparisons evaluates True. False (without
> quotes) is a constant which always evaluates False.
>
I would agree if you take 'False' as a real string which shouldn't evaluate to
False, but I had the following templatetag called:
{% mytag "some string" False %}
Which now resolved in an error:
Traceback (most recent call last):
File "/usr/local/lib/python2.4/site-packages/django/template/__init__.py" in
render_node
702. result = node.render(context)
File "/usr/local/lib/python2.4/site-packages/django/template/__init__.py" in
render
830. resolved_vars = [resolve_variable(var, context) for var in
self.vars_to_resolve]
File "/usr/local/lib/python2.4/site-packages/django/template/__init__.py" in
resolve_variable
653. raise VariableDoesNotExist, "Failed lookup for key [%s] in %r" %
(bits[0], current) # missing attribute
VariableDoesNotExist at /ais/quittung/user/list/
Failed lookup for key [False] in
As I read the code the ' or " signs are remove later in the code and return the
resulting string. So 'False' would return the String False and False could not
be resolved and won't return String False.
I thing that it is a bug. And the changeset should be re-reverted to fix this.
In the other way with context_processors defining global variables False and
True variables this can be solved :)
Regards,
Dirk
--
Echte DSL-Flatrate dauerhaft für 0,- Euro*. Nur noch kurze Zeit!
"Feel free" mit GMX DSL: http://www.gmx.net/de/go/dsl
--~--~-~--~~~---~--~~
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 ?
On 8/30/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> I would agree if you take 'False' as a real string which shouldn't evaluate
> to False, but I had the following templatetag called:
>
> {% mytag "some string" False %}
>
> Which now resolved in an error:
I'm wondering why you need to pass the literal value False into a
templatetag in the first place; if you're testing whether something
evaluates to boolean True or False, why can't you handle that inside
the tag's logic? Or if you *really* needed to pass either, why can't
you handle the conversion from some pre-defined string (e.g., 'T' or
'True' or whatnot) in said logic?
--~--~-~--~~~---~--~~
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/30/06, zzzeek <[EMAIL PROTECTED]> wrote: > > > Karl Guertin wrote: > > This is probably something I should submit a patch for in ActiveMapper > > itself, but the biggest problem with ActiveMapper is that you can't > > get at the primaryjoin and secondaryjoin attributes to do the more > > involved mapping. As a result, I normally just do assign_mapper > > throughout, as ActiveMapper and non-ActiveMapper models don't work > > well together. AM itself is like 200 lines of code on top of the SA > > core. ;] > > starting to get off topic here, while I can believe that mixing AM and > non-AM models probably have glitches (since nobody has tried it out too > much), there shouldnt be anything deeply broken with mixing the two; an > AM object is basically a regular mapped object (via assign_mapper) with > just a slightly weird way of setting up its Table/Mapper/relationships. > While i dont have the cycles to address it single-handedly, Im sure the > issues could be resolved if we come up with some decent test cases as > well as some consistent and documented ways to get at the Table/Mapper > of an AM object. We really should have a real doc for ActiveMapper. I may come up with some halfway decent ActiveMapper tests in the process of figuring out the Django-SQLAlchemy mapper; if I do, I'll make sure to send patches to SQLAlchemy. Ditto documentation. -- 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: RDBMS vs ODBMS
On 8/31/06, Karl Guertin <[EMAIL PROTECTED]> wrote: > > On 8/30/06, GinTon <[EMAIL PROTECTED]> wrote: > > I wanted to know your opinions. Since of my view point I think that the > > web frameworks with ODBMS will be the next big step. > > I prefer an RDBMS because I tend to integrate with other > projects/languages at the RDBMS level. The other advantage is that the > RDBMS are much better tested because they're in wider use. Leaving aside technical considerations, OODBMS's are simply unacceptable to many organisations. My company's clients are even wary of what they would call "new and untested" RDBMSs, such as MySQL and PostgreSQL! Alan. -- Alan Green [EMAIL PROTECTED] - http://bright-green.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: Template variable evaluation for True/False ?
On 8/31/06, James Bennett <[EMAIL PROTECTED] > wrote: On 8/30/06, [EMAIL PROTECTED] < [EMAIL PROTECTED]> wrote:> The committer russelm said: Template variable evalution should follow Python norms. As I understand it, the distinction is between the string 'False' andthe boolean False.This is correct. At render time, templates are provided Python values from a context, where logical operations can be performed on them. 'False' == True in python, so this should be reflected in the logical processing of the template. 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: RDBMS vs ODBMS
GinTon wrote: > I have seen that for web applications is best far using a ODBMS: > > 1- Objects in an OODBMS can store an arbitrary number of atomic types > as well as other objects. The fact that an OODBMS is better suited to > handling complex,interrelated data than an RDBMS means that an OODBMS > can outperform an RDBMS by ten to a thousand times depending on the > complexity of the data being handled. This is a bit off-topic, but I just wanted to share some experiences that brought me to Django, a choice I'm very happy with so far. Having spent more than 6 years with Zope and ZODB I'll have to say I'll never touch an OODBMS ever again. I realize ZODB may be perfectly fine for some situations, and there are other OODBMS's out there that are probably better, but it struck me that a lot of what makes databases cool are not yet solved well in Zope 2 / ZODB. For example: * optimization tools * dependable recovery tools and my favorite examples are inlined in responses below. > 2- Data in the real world is usually has hierarchical characteristics. > The ever popular Employee example used in most RDBMS texts is easier to > describe in an OODBMS than in an RDBMS. Django models are pretty darn straightforward. Seems like everyone in our organization, even non-programmers, feel pretty comfortable creating model files! (Not that we let everyone do it :) At least with ZODB the concept of a schema is not that strong. You can pretty much put anything you want into the database. That sounds great at first, but try debugging a program running on a 3-year-old database with 5 different versions of the same object, all lacking different attributes or storing differently typed versions of the same attribute. True, you can solve this with migrations, but at least with an RDBMS you can make the assertion that "all data is this way and will stay this way" very easily, and being to make that assertion is essential to achieve peace of mind. > 3- A query language is not necessary for accessing data from an OODBMS > unlike an RDBMS since interaction with the database is done by > transparently accessing objects. It is still possible to use queries in > an OODBMS however. A QUERY LANGUAGE You'll always want to search objects and RDBMSs are excellent at indexing and searching/ querying. ZODB doesn't really deal with this; you do that at the application level, which just isn't as robust or efficient, and you'd want something as basic as this robust and efficient. The best way to do cataloging for an OODBMS is probably to store all the metadata in an RDBMS, and in this case I have to ask: so why do you even need the OODBMS? http://www.faqs.org/docs/ZopeBook/SearchingZCatalog.html > 4- In a typical application that uses an object oriented programming > language and an RDBMS, a signifcant amount of time is usually spent > mapping tables to objects and back. This "impedance mismatch" is > completely avoided when using an OODBMS. This is taken care of by the ORM. > 5- The user of an RDBMS has to worry about uniquely identifying tuples > by their values and making sure that no two tuples have the same > primary key values to avoid error conditions. WELL-DEFINED REFERENCES RDBMSs are all about references, and ORMs can map those to "pointers". The identity of an object is well defined and understood. For Zope programmers at least, storing pointers in ZODB was pretty much black magic. Again, people would create application-level (products) solutions for pointers, something that basic should really be rock solid, well-defined, and implemented in the database itself. Oh the horrors of past... > 6- With an RDBMS it is not possible to model the dynamic operations or > rules that change the state of the data in the system because this is > beyond the scope of the database. With an OODBMS there is no disconnect > between the database model and the application model because the > entities are just other objects in the system. It is pretty easy to store anything you want in a RDMBS, including methods, just pickle it. After all, that's what ZODB does. Sorry for the Zope/ ZODB bashing. I guess I'm really *REALLY* just hoping Django stays away from mimicing Zope too much; the mixing of admin interface and model stuff is already too close for my liking (polluting the schema, IMO). To end on a good note: Zope's got good full-text indexers. I hope Django can improve in this respect. Rgds, Bjorn --~--~-~--~~~---~--~~ 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/30/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote: Hi all,Spawned by the recent discussion of the big picture of Python Webframeworks, we've decided to start a new branch of Django developmentthat uses SQLAlchemy (http://www.sqlalchemy.org/ ) as the underlyingdatabase library.What impact will this change have on existing queries? If the intention is to make the Django->SQLAlchemy model transition as easy as replacing an import statement, what is the transition plan for existing queries? Will the model.objects.filter(...) syntax continue to work for SQLAlchemy models? Is the intention to phase out the existing query syntax in preference for SQLAlchemy query syntax? Or will Django query syntax be maintained as a 'query Lite' syntax for simple problems? 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: Integrating Django and SQLAlchemy
Robin Munn wrote:
> On 8/30/06, JP <[EMAIL PROTECTED]> wrote:
> >
> > 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.
>
> SQLAlchemy already has a DynamicMetaData object that can connect model
> objects to different database engines; I currently plan to use that.
> I'll definitely take a look at the multi-db code and would welcome any
> help you might want to offer.
That makes sense. The tricky part will be assigning different groups of
tables to different DynamicMetaData instances. For instance, say you
have an application that has to connect to two different legacy
databases, one for ... uh ... zoo animals and the other, plants in a
botantic garden. The multi-db branch handles this via a setting, like:
OTHER_DATABASES = {
'zoo': { 'DATABASE_ENGINE': ..,
'DATABASE_NAME': 'legacy_zoo',
'MODELS': [ 'zoo' ] # this is an app_label
},
'botany': { 'DATABASE_ENGINE': ...,
'DATABASE_NAME': 'legacy_plants',
'MODELS': ['plants']
}}
And then mediates database access through a property on each model's
default manager. The particular config syntax is secondary to that --
the important change is that all of a model's db access goes through a
property (however indirectly) of the model, and not a single global
connection.
> Basically, don't stop work on multi-db just because I'm starting this
> branch. I might hit a brick wall and not be able to complete it, or I
> might get hit by a bus tomorrow, or whatever -- you never know what's
> going to happen. I'd welcome any ideas or code you'd like to share,
> though.
Multi-db is pretty well done, aside from the never-ending task of
merging in trunk (which just got a whole lot harder as of r3661,
unfortunately). Many of the changes in there don't really apply, since
they are pretty specific to the django stock ORM. But there are at
least three that do, I think: moving the schema manipulation sql out of
django.core.management (extra challenging to preserve the nice terminal
colors in this case), adding the Model.objects.db property for access
to the db metadata for a model, and adding methods to Manager for
manipulating the schema of the attached model (create table, load
initial data, etc).
> I like "borrowing" from other
> people's work whenever I can, it means less work for me. :-) And
> that's what open-source development is all about, isn't it?
Indeed. Laziness is a virtue, someone once said. :) I managed to clean
up my old experiment enough that the tests pass under sqlalchemy 0.2.7.
You can grab a copy here:
http://somethingaboutorange.com/mrl/projects/models.tgz
The one thing I'd advocate stealing is making the model properties
descriptors that delegate to the columns of the sqlalchemy table (or
properties of the mapper). This allows a really nice query syntax,
like: Animal.objects.filter(Environment.last_cleaned < '2001-01-01'),
which I think is a lot better than (say)
Animal.objects.filter(Environment._meta.c.last_cleaned ... ) and
provides a natural place to put and access column metadata.
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: Integrating Django and SQLAlchemy
> Then when you need to get at the > SQLAlchemy Table object, you'd do something like > Story._sa_table.some_method(). How about `Story._meta.table` or `Story._meta.c` or .columns or something, to avoid littering the model's namespace with more properties? 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: Integrating Django and SQLAlchemy
On 8/30/06, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: > What impact will this change have on existing queries? > > If the intention is to make the Django->SQLAlchemy model transition as easy > as replacing an import statement, what is the transition plan for existing > queries? > > Will the model.objects.filter(...) syntax continue to work for SQLAlchemy > models? > > Is the intention to phase out the existing query syntax in preference for > SQLAlchemy query syntax? Or will Django query syntax be maintained as a > 'query Lite' syntax for simple problems? The goal is that this will have *zero* effect on existing queries. The Django query syntax will remain exactly the same, and the database API will stay the same. The only difference is that the SQLAlchemy backend will have *extra* functionality -- namely, that people will be able to fall into SQLAlchemy syntax if they want to. 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: Integrating Django and SQLAlchemy
On 8/30/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > The goal is that this will have *zero* effect on existing queries. The > Django query syntax will remain exactly the same, and the database API > will stay the same. The only difference is that the SQLAlchemy backend > will have *extra* functionality -- namely, that people will be able to > fall into SQLAlchemy syntax if they want to. > A question then: Once the SQLAlchemy stuff is in and solid, will there be any reason *not* to use it? 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: Integrating Django and SQLAlchemy
Jay Parlar wrote: > On 8/30/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > > The goal is that this will have *zero* effect on existing queries. The > > Django query syntax will remain exactly the same, and the database API > > will stay the same. The only difference is that the SQLAlchemy backend > > will have *extra* functionality -- namely, that people will be able to > > fall into SQLAlchemy syntax if they want to. > > > > A question then: Once the SQLAlchemy stuff is in and solid, will there > be any reason *not* to use it? The Django query syntax is a great way to map a flattened dict to a query. A flattened dict like, say, GET or POST data. ;) 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: Integrating Django and SQLAlchemy
There I go, answering the wrong question... I should learn not to post after 10 pm, too many brain cells are asleep and the remainder can't handle typing and thinking at the same time. The reason not to use it I guess would be that you already have a working app and you don't need it. 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: Integrating Django and SQLAlchemy
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 -~--~~~~--~~--~--~---
generic-auth and per-object-permission integration
So I should probably get started on the generic-auth and per-object-permissions (hereafter pop) integration soon. I've had problems trying to merge changes from the trunk into the generic-auth branch, so I'd just assume call that branch dead. The actual generic-auth code is just a patch to the trunk [1] The easiest way integrate the two would probably be for me to patch the per-object-permissions branch. I suppose the other option, for the anal-rentively inclined, (which very often includes me ;) would be to start a new-auth branch, merge the pop changes to it (or even copy the existing pop branch, yeah, ick.), and apply the generic-auth patch to it. This sounds like a total pain in the ass to me. /me grumbles something about his love/hate relationship with svn, specifically merge I am presupposing that gen-auth and pop should be merged together before they get merged to the trunk. If you disagree, let me know. So there's the logistics. Here are the rest of the plans for getting this into the trunk. After the two codebases (gen-auth/pop) are integrated, I plan to refactor out a couple of functions from the django.contrib.models.User.has_perm method in the pop branch. After that, the has_perm method should die. (Some other User methods may suffer a similar fate) I'll put in some backwards compatibility code (that *doesn't* support pop), but I think it should be gone by 1.0. I also want to take a look at how the Meta attributes work for activating this stuff. I'd like to make it a little more generic, but I'll bring it up again after I've taken a look at the code. Thoughts, comments? Joseph [1] http://code.djangoproject.org/attachment/wiki/GenericAuthorization/generic-auth.diff --~--~-~--~~~---~--~~ 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?
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: Django and psycopg2 problems
Jacob Kaplan-Moss wrote: > On Aug 28, 2006, at 2:50 PM, Adrian Holovaty wrote: > > On 8/28/06, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: > >> Are the any objections to changing the psycopg2 backend to behave the > >> same was as the other ones (knowing that it's actually a step > >> backwards)? Eventually the right thing to do would be to make the > >> *other* backends behave this way, but that's all caught up with > >> unicodification, and I'd like to move towards consistency first, and > >> then correctness when it's ready. > > > > It's definitely a step backward, but it's probably better to be > > consistent than "more correct" in this case. Fine by me -- > > Yeah, it sucks, but consistancy seems important to me, too. I've > checked in the "fix" as [3675]; it's pretty easy to remove later. > > Jacob Aww... this is a regression from ticket #2514 and changeset [3565]. 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. vic --~--~-~--~~~---~--~~ 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
On Aug 31, 2006, at 1:31 AM, 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? +1. In addition, we can save a few SQL queries every request. －Cheng Zhang http://www.ifaxian.com 1st Django powered site in Chinese ;-) --~--~-~--~~~---~--~~ 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
I should have elaborated on my problem. 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. vic crankycoder wrote: > Jacob Kaplan-Moss wrote: > > On Aug 28, 2006, at 2:50 PM, Adrian Holovaty wrote: > > > On 8/28/06, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: > > >> Are the any objections to changing the psycopg2 backend to behave the > > >> same was as the other ones (knowing that it's actually a step > > >> backwards)? Eventually the right thing to do would be to make the > > >> *other* backends behave this way, but that's all caught up with > > >> unicodification, and I'd like to move towards consistency first, and > > >> then correctness when it's ready. > > > > > > It's definitely a step backward, but it's probably better to be > > > consistent than "more correct" in this case. Fine by me -- > > > > Yeah, it sucks, but consistancy seems important to me, too. I've > > checked in the "fix" as [3675]; it's pretty easy to remove later. > > > > Jacob > > Aww... this is a regression from ticket #2514 and changeset [3565]. > > 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. > > vic --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
