Re: dbsettings, and user configurable app settings
On Wed, Mar 10, 2010 at 7:51 AM, Brian Rosner wrote: > > On Mar 10, 2010, at 7:16 AM, Joan Miller wrote: > >> It's a disaster from the maintenance view point. If it were not so, >> then people would not be proposing to refactor the settings as has >> been made in Pinax, or from multiple posts so many times. > > Like I mentioned in the post you made to the pinax-core-dev mailing list the > problem Pinax is trying to solve is *not* because the settings are written in > Python, but rather loading order and scope. Many projects quickly realize > that running a Django project with a single settings file is nearly > impossible with different environments all interacting with a single code > base. Some projects turn to importing a local_settings.py file which is what > Pinax currently does. This has worked wonderful for us for years. > [snip] The local_settings.py convention (thanks, Pinax!) has worked well for us in an environment with multiple dev, test, and production server tiers. We solve the DATABASE_PASSWORD= issue by only allowing the DBAs access to local_settings.py on production, and having an svn:ignore rule that prevents anyone from accidentally checking it in to version control. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Django, The Web Framework for perfectionists and innovative with rechargeable batteries.
On Fri, Jul 30, 2010 at 2:57 PM, Jerome Leclanche wrote: > [2] People who do have ideas and do write code, but still get rejected > because their ideas don't conform to whatever the core devs need in > their websites. I don't think that's a fair criticism at all. > ... > Nice job scaring that poor guy who was just trying to be helpful. His > first post is met with so much hostility and elitism, I can't imagine > being him right now. Ignoring language and newbie barriers, it was not a django-dev post, and clearly had no spark of idea. I think jacob and others are extremely fair and tolerant in moderating this list. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Oracle: call for testing
Here is the current status of Oracle support: - Some of the backend files are already in subversion trunk, but not enough to make it functional. Don't bother testing (or patching) Oracle support in the trunk--the branch is where the action is. - Some Colorado developers, along with Jacob Kaplan-Moss, made a valiant attempt to finish Oracle support at a sprint about two months ago. That's now the boulder-oracle-sprint branch. - To run the unit test suite, do "python tests/runtests.py --settings=myproject.settings" from the root of the boulder-oracle-sprint branch. Make sure myproject.settings is a python module in your PYTHONPATH that is configured to connect to an Oracle database. The Oracle user you specify must have DBA-type privileges, since the tests create and destroy tables, indexes, triggers, and tablespaces. (Also don't include a CACHE_BACKEND in settings.py, or the cache-related tests will fail.) - Currently, only two tests fail against Oracle. We could really use help fixing those! - A bigger problem is the potential column name collision owing to the fact that our paging query uses a "SELECT *" construct around the main SQL. (Don't scold me; we're trying to fix it.) - Another issue is that Date and DateTime fields show up as Boolean values in the Admin. - I merged changes from the django trunk into the boulder-oracle-sprint branch today, and will continue to do so on a weekly basis until Oracle support is in the trunk. Questions about Django development in general are answered here: http://www.djangoproject.com/documentation/contributing/ --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: Error ORA-00918 (column ambiguously defined)
This is now fixed in the current boulder-oracle-sprint branch, as of changeset [4277]. --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: Oracle: call for testing
Andreas, I finally got around to applying and testing your patch. Thanks very much--it makes the Oracle test environment much more flexible. --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: Oracle indexes and tablespaces
At the Django-Oracle sprint a couple months ago, we discussed having an optional "tablespace" parameter when defining models, but not a separate one for the index tablespace. We didn't get around to implementing it. In Oracle-land, your requirement is actually common, not unique. I think it's important to be able to specify table and index tablespaces if we want Django to fit well into real Oracle environments. For now, I'm doing "manage.py syncdb" against a local Oracle XE instance I control, then taking the output of "manage.py sqlall" and editing it as necessary for production. Someone mentioned a branch or patch that allowed for passing through arbitrary additional arguments to a Model. That could be a clean solution to this problem--does anyone know where such code lives now? --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: SQL generated from oracle-boulder-sprint doesn't work with Oracle9i
Frank, I've been doing as much maintenance and bug fixing as I can on the boulder-oracle-sprint branch. I test against 9i as well as 10g XE. If you could do as James suggests and post a detailed bug report at http://code.djangoproject.com/, I'll take a look and get it fixed. thanks, Matt On Mar 19, 1:58 am, "frank h." <[EMAIL PROTECTED]> wrote: > Hello, > I am trying to use Django with an Oracle9i database (the server > version is "Oracle 9i Enterprise Edition Release 9.2.0.7.0 - 64bit > Production") > > using cx_Oracle, i can connect to the database fine. sqlplus and all > other tools I've tried connect just fine. It is upon executing > > manage.py install <> > > that things go wrong, the database engine complains about the SQL that > django is generating. I am by no means a database or SQL expert, but I > showed the output of manage.py sqlall <> to our DBA, and he > pointed out the syntax errors to me. > > My questions are: > - who is maintaining this oracle branch and how can I get in touch > with them (I looked on the wiki but found no branch homepage, this > would maybe be a good idea to create?) > - can somebody look at the SQL I get from manage.py and either > confirm that its a problem (in which case I could file a bug) or tell > me what is going wrong? > > I can't even get the admin to install, this has nothing to do with > models that I have created. I assume though that the oracle branch is > able to create the admin tables in an oracle database (I could not > find any information to the contrary) > > ok, thanks for your help > -frank --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Oracle patch is ready
The "boulder-oracle-sprint" branch is ready to come home. We made a wiki page describing the goals and status of the code (quick summary: Oracle works and we think it's done, unless you tell us otherwise). Attached to that page is a patch against rev 5036 of the trunk. See here: http://code.djangoproject.com/wiki/OracleBranch The diff itself is here: http://code.djangoproject.com/attachment/wiki/OracleBranch/django-oracle-rev5036.diff This is a "non-trivial patch," we believe, so rather than attaching it to the closed Trac bug #1990, we're advertising it here as recommended on the "Contributing to Django" page. There are some minor architectural changes in there, although we've made every effort to minimize the overall deltas. Please review the patch if you're able to and let us know what you think. --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: Oracle patch is ready
+1 on what Jim said, and since we are using this code in production at Array BioPharma, we will stay on top of it. If you need an individual point of contact, I can be that, and Ian Kelly and I will be monitoring the mailing lists and Trac more actively and responding to Oracle-related issues. Matt On Apr 19, 10:08 pm, Jim Baker <[EMAIL PROTECTED]> wrote: > Jacob, > > As we discussed at PyCon, we can make an even stronger commitment, > since this continues to be an official project for the Front Range > Pythoneers in Boulder. But people ultimately get this work done, so > kudos go to ring leader Matt Boersma, the intrepid Ian Kelly, Eric > Dobbs, Matt Drew, Michelle Cyr, and Mitch Smith for making this > happen. > > And a special thanks to you for coming out on an early flight from > Lawrence and working with us in Boulder on Saturday, Nov 4, that did > make all the difference. (For those interested in user group > sprinting, I'll plug it here,http://wiki.python.org/moin/BoulderSprint > :) > > - Jim > > On Apr 19, 10:08 pm, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]> > wrote: > > > On 4/19/07, Matt Boersma <[EMAIL PROTECTED]> wrote: > > > > The "boulder-oracle-sprint" branch is ready to come home. > > > Wahoo!! > > > Just to clarify, Matt: you're willing to commit to maintaining Oracle > > support once we merge this into trunk, yes? If so, I'm +1 on merging > > this in (there's a few things we had to do I'm not 100% thrilled with > > -- in particular the QS method overriding hack) but I'm OK fixing that > > stuff a bit later. I'd love to get this to be an "official" feature! > > > 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?hl=en -~--~~~~--~~--~--~---
Re: Oracle patch is ready
Ben Khoo already found a good bug (#4093) that we fixed, and in the process we found a problem we'd created for Postgres that wasn't caught by any of the tests. So we fixed that and added a "datatypes" test to modeltests. So there is a slightly newer patch available now: http://code.djangoproject.com/attachment/wiki/OracleBranch/django-oracle-rev5046.diff We'll try not to do this again so people can focus on the content of the patch for a bit, but these two things needed to be fixed ASAP. If you're testing the boulder-oracle-sprint branch directly, please update. Matt On Apr 20, 10:03 am, "Adrian Holovaty" <[EMAIL PROTECTED]> wrote: > On 4/19/07, Matt Boersma <[EMAIL PROTECTED]> wrote: > > > The "boulder-oracle-sprint" branch is ready to come home. > > Congrats, guys! Thanks to all of you for your hard work. I'm +1 for > merging it, too, once we've taken a look at it. > > Let's organize the merge process. Malcolm, since you've been dealing > with query.py and other databasey parts of Django, do you want to take > the lead on the merge? Or Jacob? I could get to it next week if you > guys are busy. > > 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?hl=en -~--~~~~--~~--~--~---
Re: Oracle patch is ready
That's a good point, Ben. There isn't any way to propagate the db_tablespace parameter back to models not directly under your control, like auth, sessions, etc., so the db_tablespace parameter we added is only a halfway solution. Our thinking was that for any "real" Oracle deployment, chances are high that you'll want to take the output of "./manage.py sqlall" and at least modify the index and row tablespaces, as well as create more specific grant permissions (and change LOBs to be stored out-of-table, and...). We are unlikely to please a full-time Oracle DBA with the DDL we create no matter what we do, given the richness of Oracle's storage options. Having the db_tablespace parameter makes at least the models under your control more self-documenting. But it's not perfect. Here are the three options I can think of: - Leave as-is, realizing it helps somewhat - Drop the "db_tablespace" and index tablespace keywords altogether to avoid this confusion - Add a mechanism for a default global tablespace and global index tablespace that apply unless overridden in a specific model or column Thoughts? Matt On Apr 22, 10:02 pm, benk <[EMAIL PROTECTED]> wrote: > Hi, > > I have been using the Oracle branch now for a few months and it is > looking really good. > > I have a question regarding the use of the 'db_tablespace' option in > the Meta class. I am able to set this option within my application and > successfully perform a syncdb that will place all my tables in the > correct tablespace. The question/issue that I am having is that I > cannot see a way of instructing any other application (such as > authentication) to also create its tables in the tablespace of my > choosing. > > To my understanding the application will either create its tables in > the tablespace specified in its own models.py or it create its tables > in whatever the default tablespace happens to be. This results in > tables being created in several different tablespaces. > > For my 2c worth, if this cannot already be done by the current Oracle > database framework, I think that would be a beneficial addition if > only to provide completeness to the option to assign tablespaces. > > Regards > Ben Khoo > > On Apr 21, 1:54 am, Matt Boersma <[EMAIL PROTECTED]> wrote: > > > Ben Khoo already found a good bug (#4093) that we fixed, and in the > > process we found a problem we'd created for Postgres that wasn't > > caught by any of the tests. So we fixed that and added a "datatypes" > > test to modeltests. > > > So there is a slightly newer patch available > > now:http://code.djangoproject.com/attachment/wiki/OracleBranch/django-ora... > > > We'll try not to do this again so people can focus on the content of > > the patch for a bit, but these two things needed to be fixed ASAP. If > > you're testing the boulder-oracle-sprint branch directly, please > > update. > > > Matt > > > On Apr 20, 10:03 am, "Adrian Holovaty" <[EMAIL PROTECTED]> wrote: > > > > On 4/19/07, Matt Boersma <[EMAIL PROTECTED]> wrote: > > > > > The "boulder-oracle-sprint" branch is ready to come home. > > > > Congrats, guys! Thanks to all of you for your hard work. I'm +1 for > > > merging it, too, once we've taken a look at it. > > > > Let's organize the merge process. Malcolm, since you've been dealing > > > with query.py and other databasey parts of Django, do you want to take > > > the lead on the merge? Or Jacob? I could get to it next week if you > > > guys are busy. > > > > 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?hl=en -~--~~~~--~~--~--~---
Re: Oracle patch is ready
I had purposely let this thread dangle, hoping Malcolm or Adrian or Jacob might weigh in and decide the "db_tablespace" minor controversy. But I hope this unresolved issue isn't perceived as holding up integration of the Oracle patch. I don't think it should. At worst, we could strip out the "db_tablespace" options altogether to simplify the patch, then resurrect it as a separate patch on trunk once we know which of the below options is preferred. I also think it's ok to leave it as-is for now. So this is my "ping" to see if there's any general feedback on the patch, and if there's any way we can facilitate it getting incorporated. Not a complaint! [ducks head] thanks, Matt On Apr 23, 7:21 pm, benk <[EMAIL PROTECTED]> wrote: > Hi Matt, > > I can see where you are going regarding the manual "massaging" of > "sqlall" output to create the database tables. My primary reason for > the post was to ensure that I did not miss a piece of documentation > showing how the tablespace could be set for other applications. > > To clear up potential misconceptions, I am most certainly not an > Oracle DBA. Far from it. I am merely a lowly programmer who is > currently working with Django. > > For the moment, I have worked around the issue of tables appearing in > different tablespaces by creating an Oracle user configured to use a > specific default tablespace which is the same as the db_tablespace. > This means that for applications like auth where the db_tablespace is > not specified, Oracle will create the table in my configured default > tablespace. All of this of course happens at the user creation level > in Oracle and makes the explicit setting of the db_tablespace option > redundant. > > In my personal opinion (that I encourage those with higher powers to > overrule as required) I think that it is leaving the db_tablespace > option "as is" would be completely acceptable with the addition of a > note to prevent misconceptions like mine. The only disadvantage that I > can see with this path is that this option is a "halfway solution" as > you put it and only applies to Oracle. This may lead to a longer term > cluttering of the Django API for limited gain. > > Ben --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: Question for Oracle Boulder sprinters
On May 11, 8:37 am, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > ... > So should the Oracle branch be ignoring the null attribute when > blank=True and assuming null=True in that case? I think that's reasonable. It may mean a couple of unit tests fail, so we can either modify them or at least document that this is expected with the Oracle backend. We had considered doing this before, but probably opted against it since we were focused on passing all the tests. Our current approach in this case is to map an empty string to a single space char when storing, and the opposite when loading. We'll try to implement your suggestion above ASAP unless someone has major objections. Matt --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: Results of Moscow local sprint (newforms-admin and Oracle pooling)
That's pretty cool! I've attempted this in the past, but always ended up with test case failures, and didn't see any speedups, so I abandoned it. I'll try this out when I have time. Could someone repackage it as a proper patch attached to ticket #7732? I think I'd rather see it folded into the trunk for the Oracle backend, rather than as a separate backend. We require cx_Oracle 4.3.1 or later, so there shouldn't be any issues with pooling support. But I suppose that relegates this to post-1.0. Matt On Jul 15, 2:38 pm, Ivan Sagalaev <[EMAIL PROTECTED]> wrote: > Hello! > > Last Saturday we've gathered in Moscow at Yandex and had a sprint aimed > at newforms-admin bugs. > > It didn't work as smooth and effective that we hoped but all the > problems are more or less explained by the lack of my experience as a > sprint organizer. We'll try harder next time! > > Nonetheless... We worked on a few bugs which all tagged with the keyword > "yandex-sprint"[1]. Many thanks to Honza Král who was on #django-sprint > that day and promptly triaged our tickets. Now I'd like to ask someone > of committers to take a look at them. > > One ticket deserves a special note. There were 3 guys who were working > not on newforms-admin bugs but on a new Oracle backend with support for > pooling connections. They did finish it and submitted it in Trac[2]. The > ticket already has a note about repackaging the backend as a patch. > However I think it worse to ask opinion of guys that support the > official Oracle backend on what's better to do with this code: make it > another backend, make it an external backend, replace current backend? > > Thanks! > > [1]:http://code.djangoproject.com/query?keywords=~yandex-sprint&order=pri... > [2]:http://code.djangoproject.com/ticket/7732 --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
You've broken Oracle
This is just a heads up since clearly some committers must be unaware: checkins of the last two days have created 27 (yes, twenty-seven) new test case failures for Oracle. I had been working on cleaning up the existing few failures for the Oracle backend, but unless those who actually committed the weekend's changes are able to look at this, Oracle should not be included in the 1.0 release IMHO. I realize running all the backends (and all three pythons) to check for regression failures before committing code is onerous. However, that's what I do, and now I'm reminded why. It's not enough to see that the code runs on sqlite or postgres and call it a day. Here is Leo Soto's buildbot, so you can see what I'm talking about: http://certenium.ingenium.cl:8080/hudson/job/django-trunk/ I'll do my best to fix some of these as time permits, but I'm hoping others will pull together to rectify this quickly. Thanks! --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: You've broken Oracle
Thanks very much for the pointer, Ramiro. It was indeed changes to the "extra_select" QS param that caused Oracle problems, and I've taken a similar approach to yours in fixing it. Rather than flag "row_number()" as an extra_select parameter (and then try to clean up after it later), Oracle now just uses the default set_limits and clear_limits methods and does all extra query munging in its as_sql() method. And instead of doing an outer SELECT *, we SELECT specific columns (or aliases) by name and ignore our row_number() column, which is only used in the WHERE clause. This seems to fix most of the failures. I'll check it in soon when I'm sure it's not causing any new problems. On Aug 18, 2:20 pm, "Ramiro Morales" <[EMAIL PROTECTED]> wrote: > Matt, > > On Mon, Aug 18, 2008 at 4:04 PM, Matt Boersma <[EMAIL PROTECTED]> wrote: > > > Here is Leo Soto's buildbot, so you can see what I'm talking about: > >http://certenium.ingenium.cl:8080/hudson/job/django-trunk/ > > > I'll do my best to fix some of these as time permits, but I'm hoping > > others will pull together to rectify this quickly. Thanks! > > Some of these failures might be related to the changes in the `extra_select` > (and `extra_select_params` that got deleted) Query class attributes introduced > in r8426 because, as you know, the Oracle backend (and the MS SQL Server > backends) uses `extra_select` to insert a synthetic placeholder needed to use > the ORDER_BY function to emulate LIMIT+OFFSET. > > FWIW, in my work on a MS SQL Server backed I circumvented the bulk of the > problem by accident (actually, because this is one of the things that allowed > me to get a whole bunch of the Django test suite to start passing on SQL > Server 2005 whose SQL dialect also has the ORDER_BY function) some time ago by > migrating away from using `extra_select` to using the `ordering_aliases` > attribute to handle the placeholder by appending to it: > > http://code.google.com/p/django-pyodbc/source/browse/branches/ramiro/... > > Later on during the lifetime of the query, the `execute_sql()` Query method > will take care of ignoring that alias. > > This also allowed me to do away with the `set_limits()` and `clear_limit()` > custom Query class methods. > > I don't know if this is also possible for the Oracle backend, hopefully it is. > > HTH, > > -- > Ramiro Morales --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: You've broken Oracle
Hi Justin,
Sorry, I should have run the gis tests as well. (Is that Malcom
snickering I hear? I'm chastened.)
Did GeoDjango break in r8426 then, as Oracle in general did? That's
where extra_select changed. I can see how our new code in r8445
breaks on your function column.
I'll look at it today and see if I can come up with a fix.
Matt
On Aug 20, 10:27 am, Justin Bronn <[EMAIL PROTECTED]> wrote:
> > Rather than flag "row_number()" as an extra_select parameter (and then
> > try to clean up after it later), Oracle now just uses the default
> > set_limits and clear_limits methods and does all extra query munging
> > in its as_sql() method. And instead of doing an outer SELECT *, we
> > SELECT specific columns (or aliases) by name and ignore our
> > row_number() column, which is only used in the WHERE clause.
>
> > This seems to fix most of the failures. I'll check it in soon when
> > I'm sure it's not causing any new problems.
>
> This approach breaks slicing for Oracle in GeoDjango. Specifically,
> getting rid of the `SELECT *` and manually specifying the columns has
> introduced side effects. The following example will show the problems
> -- here is a simple geographic model:
>
> class City(models.Model):
> name = models.CharField(max_length=30)
> point = models.PointField()
> objects = models.GeoManager()
>
> In 8425, here's the SQL that `City.objects.all()[0]` would produce:
>
> SELECT * FROM (SELECT (ROW_NUMBER() OVER (ORDER BY "GEO_CITY"."ID" ))
> AS "RN", "GEO_CITY"."ID", "GEO_CITY"."NAME",
> SDO_UTIL.TO_WKTGEOMETRY("GEO_CITY"."POINT") FROM "GEO_CITY") WHERE rn
>
> > 0 AND rn <= 1
>
> As you can see, I need to wrap the geometry column with a function
> call that converts the column into an acceptable format. With the
> changes in r8445, this is the broken SQL that is produced:
>
> SELECT "ID", "NAME", "POINT") FROM (SELECT ROW_NUMBER() OVER (ORDER BY
> "GEO_CITY"."ID") rn, "GEO_CITY"."ID", "GEO_CITY"."NAME",
> SDO_UTIL.TO_WKTGEOMETRY("GEO_CITY"."POINT") FROM "GEO_CITY") WHERE rn
>
> > 0 AND rn <= 1
>
> There are a few problems here. The first is that the `col.rsplit('.',
> 1)[1]` logic is too brittle to handle a column wrapped in a stored
> procedure. But the greater issue is that to fix this in GeoQuery is
> that I need to make `get_columns` aware if it's being called for an
> outer select or the inner select, i.e., I'll have to set an alias on
> the inner select while not putting any function wrapping on the outer
> select. I currently don't know how to do this other than adding extra
> keyword parameters in my overridden implementation that may be used by
> an overridden `as_sql` used only for Oracle just for this purpose.
> Needless to say, this isn't trivial -- unless there's other ideas on a
> different approach I may have to drop Oracle support for GeoDjango in
> 1.0. I'm hesitant to be rewiring internals this close to the deadline
> instead of focusing on documentation.
>
> -Justin
--~--~-~--~~~---~--~~
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?hl=en
-~--~~~~--~~--~--~---
Re: You've broken Oracle
On Aug 20, 10:50 am, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> There's one SQL syntax error that I can't fix, however (in
> regressiontests/queries/models.py). I'll look at the pickling issue
> there, but the SQL problem I can't debug.
If you mean this one:
Item.objects.dates('created', 'day')[0]
DatabaseError: ORA-00923: FROM keyword not found where expected
then I'm on it. Thanks for looking at the other tests.
The pickling problem arises because we construct our OracleQuery class
dynamically, so it doesn't match the module path when pickle attempts
to resurrect it. Ian Kelly and I stared at this one for a while but
didn't come up with a good fix yet.
(If anyone out there uses Komodo, here's my tip of the day. Use
manual breakpoints:
from dbgp.client import brk; brk()
That's the only way I've found to fire up the debugger reliably when
inside doctests.)
Matt
--~--~-~--~~~---~--~~
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?hl=en
-~--~~~~--~~--~--~---
Re: You've broken Oracle
On Aug 20, 1:01 pm, Justin Bronn <[EMAIL PROTECTED]> wrote:
> > Item.objects.dates('created', 'day')[0]
> > DatabaseError: ORA-00923: FROM keyword not found where expected
>
> That's the exact error that's giving me problems -- I think it's one
> of the same issue as I'm having. It's because of the `col.rsplit('.',
> 1)[1]` logic in Oracle's `as_sql` when doing offsets. In other words
> when the column is wrapped in a function (like the datetime SQL is)
> then there will be a parenthesis after the quote still in the column
> name.
That's true, and it's obviously a bug, but sadly there are a couple
other errors involved in this particular failure. First is that one
column is a TRUNC(date) function without a column alias, so there's no
way to SELECT that in the outer query. Second is that the query uses
DISTINCT, but we blindly injected our ROW_NUMBER() function as the
first column, which creates invalid SQL since DISTINCT must appear
before the column list. Then there's our mis-parsing of the column
name with parentheses.
I now think reintroducing the extra_select approach might work better,
and perhaps could fix the GeoDjango issues as well.
--~--~-~--~~~---~--~~
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?hl=en
-~--~~~~--~~--~--~---
Oracle IntregrityError and get_or_create test case
I noticed that in the get_or_create test case, Oracle fails because the cx_Oracle database driver raises a DatabaseError, not a more specific IntegrityError, when an INSERT lacks a required field. (Malcolm anticipated this in his commit message for r8450.) Looking at the C code for the driver, it appears cx_Oracle maps some ORA- error codes to IntegrityError, but not this one (ORA-01400). I think it's just a bug in cx_Oracle, and I've posted these same details to their mailing list to see if the author would fix it. So this is just a heads up to keep anyone from trying to fix the get_or_create test case for Oracle right now--I think it should continue to fail until we know whether or not the driver will be changed. --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: Oracle IntregrityError and get_or_create test case
On Aug 22, 5:56 pm, Justin Bronn <[EMAIL PROTECTED]> wrote: > FYI, r8471 fixed my problems and all Oracle GeoDjango tests pass > again. Thanks. That's good news, Justin--thanks for verifying! (I have access to 9i and 10g servers--not just XE--but spatial isn't licensed for any of them so I had to cross my fingers.) To follow up on the get_or_create failure, where the cx_Oracle driver raises a more generic DatabaseError instead of an IntegrityError when trying to INSERT a row lacking a required column value: Anthony Tuininga, cx_Oracle's author, agreed that ORA-01400 should map to IntegrityError and already commited that change to his trunk C code. (Thanks, Anthony!) So now we can fix the test case in theory by checking the backend and driver version, and if it's 4.4.0 or earlier, we can continue to fail with "Fail: this version of cx_Oracle incorrectly raises DatabaseError" or the like. However, I grep'ed the Django source and found two cases where we catch IntegrityError specifically. cx_Oracle probably misbehaves there currently, but I'm not sure how common these code paths are and what errors could result. Currently, our docs say we require cx_Oracle version 4.2.1 or later. It's not reasonable to expect Django users--especially ISPs and corporations-- to upgrade to svn trunk and build the driver. We could ask Anthony to do a hurry-up 4.4.1 release with this fix in it, but even so it's a lot to ask everyone to upgrade to a brand-new driver version. On the other hand, we're not talking about a large number of Django/Oracle users currently, but that should change when we have an official 1.0 release. Opinions? --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: Oracle IntregrityError and get_or_create test case
Hi Malcolm, I can wrap the execute() and executemany() calls in oracle\base.py in a try/except that re-raises this specific error as an IntegrityError: try: return Database.Cursor.execute(self, query, self._param_generator(params)) except DatabaseError, e: # cx_Oracle <= 4.4.0 wrongly raises a DatabaseError for ORA-01400. if e.message.code == 1400 and type(e) != IntegrityError: e = IntegrityError(e) raise e This seems to work fine, fixes the get_or_create test case, and doesn't require changes outside the oracle backend. Let me know if you think that's acceptable. On Aug 23, 10:47 am, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > On Sat, 2008-08-23 at 08:07 -0700, Matt Boersma wrote: > > [...] > > > However, I grep'ed the Django source and found two cases where we > > catch IntegrityError specifically. cx_Oracle probably misbehaves > > there currently, but I'm not sure how common these code paths are and > > what errors could result. > > > Currently, our docs say we require cx_Oracle version 4.2.1 or later. > > It's not reasonable to expect Django users--especially ISPs and > > corporations-- to upgrade to svn trunk and build the driver. We could > > ask Anthony to do a hurry-up 4.4.1 release with this fix in it, but > > even so it's a lot to ask everyone to upgrade to a brand-new > > driver version. On the other hand, we're not talking about a large > > number of Django/Oracle users currently, but that should change when > > we have an official 1.0 release. > > > Opinions? > > I personally don't view this as being controversial. We should make it > work with the current cx_Oracle releases that are in common use. We've > done this before (e.g. MySQL releases, special handling based on version > numbers, etc). Not supporting the active userbase would be dumb. > > I'll have a think about what we can do to handle this properly: I would > definitely like to catch IntegrityError for those databases that support > it, so that other generic DatabaseError situations are *not* caught and > are passed onto whatever higher error handlers are in place. A > backend-specific function for checking the exception type (that is the > default for almost everybody and special for Oracle) and then reraising > if it's not what we want is one solution that comes to mind. Something > like that should be possible. > > Regards, > Malcolm --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Oracle IntregrityError and get_or_create test case -- MySQL also
On Aug 25, 10:51 am, "Karen Tracey" <[EMAIL PROTECTED]> wrote: > I just noticed that the MySQL backend also fails on this get_or_create > test. It is returning an OperationalError instead of an IntegrityError. > Looks like MySQL returns errno 1364 (ER_NO_DEFAULT_FOR_FIELD) in this case > but this is not recognized as anything special in MySQLdb so it's just > mapped to a general OperationalError. I don't see a corresponding place in > the mysql backend to do the sort of catch & transform you have found to do > with Oracle? OperationalError according to PEP 249 is for "errors that are related to the database's operation and not necessarily under the control of the programmer, e.g. an unexpected disconnect occurs, the data source name is not found, a transaction could not be processed, a memory allocation error occurred during processing, etc." That doesn't seem to fit an INSERT lacking a NOT NULL value (and no table default value). So at first glance, I'd say that's a bug in MySQLdb that should be rectified so it also raises IntegrityError. And following what I just committed in [8545], we should perhaps find a way to work around the driver so we can rely on IntegrityError in this situation. But since the MySQL backend isn't as customized as Oracle, there's no existing place to trap this. We could add execute() and executemany() to a new MySQLCursor class to fix it similarly, but as Senator Obama likes to say, "that's above my pay grade." > Karen --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: Testing speedup checked in
As another data point, our nightly run of the test suite against Oracle just completed. We see the same test failures we had previously--nothing new--but it was *much* faster as hoped. Python 2.5, Django 1.0.x: 24510 secs. Python 2.5: Django trunk: 3024 secs. Previously, trunk took about ten minutes longer than the 1.0.x branch. (This is on a puny Pentium 3 box with 512MB RAM running both Oracle 10g and the django tests, so don't fret about the absolute times.) So let me thank profusely Karen and everyone else who pitched in on this change! It will make a very practical difference in helping Ian Kelly and I to keep the Oracle backend in shape. Matt On Jan 16, 8:17 am, "Karen Tracey" wrote: > On Fri, Jan 16, 2009 at 9:43 AM, Alex Gaynor wrote: > > PgSQL is indeed PostgreSQL. Yes, I do still get the failures pre-fast > > tests, I guess I'd never run those tests. I would like to say that when I > > went back to test that the tests were unbearably slow, so that makes me > > super happy about the new fast tests, thanks for all your hard work. > > Yeah, one consequence of the new faster tests may be people start running > the full suite more often and notice lurking errors that have been out there > but just unseen. The machines where I have Oracle and PostgreSQL set up are > old and slow and took 8+ hours to run the full Django suite prior to these > changes, meaning I would really never run the full suite for those > backends. Now I can run them in an hour or so -- still not real speedy but > it's at least feasible to run the full suite. > > Sadly, only a few of my test setups pass completely clean. I see the errors > you pointed out on PostgreSQL, others related to referential integrity & > fixtures on InnoDB, some Windows temp file problems, some sqlite problems > related to a specific sqlite/Python level, some Oracle errors that I think > are something wrong in my DB setup, etc. On my wish list is getting some of > these resolved, but I haven't had time to focus on that yet. What I did for > the rollback test changes was manually verify that any errors/failures I saw > with the changes were identical to what I saw without them. > > I do think all the problems I see (with the exception of the Oracle ones > which I suspect are database setup related, but I've not had a chance to > investigate much there) are either known with open tickets or known > unfixable (e.g. sqlite bug for a specific version). It might be nice if we > had a way to flag such things as "expected to fail (at the moment, in this > configuration)" so that it's easier to run the full suite on a wide range of > configurations and get a quick confirmation from the output that the results > are as expected, even if there are known failures in some cases at the > moment. I think I've seen this idea discussed before...but again I haven't > had much time to look into it yet. > > Karen --~--~-~--~~~---~--~~ 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Controlling form/widgets output
On Jan 22, 2009, at 9:23 PM, catsclaw wrote: > > On Jan 22, 12:12 am, Jacob Kaplan-Moss > wrote: >> Why don't we start over here: what is the problem? What did you try >> do >> do? What did you expect to happen? What actually happened? > > Here's another problem I'm stuck at. I'm trying to determine, > within a widget, whether I'm being asked to draw a field that is > required, so I can add JavaScript validation on the form submit. Is > this possible? That's an excellent question for the django-users list. Here we discuss the development of django itself. --~--~-~--~~~---~--~~ 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Is the Oracle backend passing the model_forms_regress test?
On May 6, 2009, at 8:50 PM, Karen Tracey wrote: > On Wed, May 6, 2009 at 10:34 PM, Leo Soto M. > wrote: > > While testing the django-jython oracle backend I get an ugly failure > on model_forms_regress, Yes, I saw this too. I'll check in a fix tomorrow a.m. if no one beats me to it. > --~--~-~--~~~---~--~~ 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Oracle savepoints
On Sat, May 16, 2009 at 1:42 PM, Richard Davies wrote: > > My question is effectively the same as asking if the test suite passed > on Oracle between [8314] in August 2008 and [10022] in March 2009. > > I assume that it must have passed during those six months (Django 1.0 > was [8961] in September 2008!), which would imply that Oracle > savepoints were implemented for reason (a) to add the feature rather > than reason (b) by necessity. I think Malcolm implemented this in the Oracle backend rather than Ian K. or myself. The test suite has been passing all but a few cases on Oracle in general since before the 1.0 release. So I'd say the answer is a). --~--~-~--~~~---~--~~ 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Oracle branch: review notes
On Jun 1, 8:50 am, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]> wrote: > ... Is there perhaps a VMWare > image of a pre-installed Oracle that I can test this stuff against? Oracle had a developer program called "Oracle By Example" (OBE) that provides a VMware image with RedHat, Oracle 10gR2 RAC, etc. But I can't seem to find the actual download for it any longer, and there's no Oracle image at VMware's "Virtual Appliances" page. I'd encourage you to revisit http://www.oracle.com/technology/software/products/database/oracle10g/index.html and download the .deb or .rpm and give it another try. Oracle installs used to be tricky, but since they packaged XE this way it's been painless for me, and obviously having a working setup would be essential for a buildbot environment. If you see specific errors, mail me at matt (at) sprout (dot) org and I'll help. Or, if you're using VMware 6.0 on Linux (host), I'll build you a Ubuntu or RedHat VMware image with Oracle 10g. Let me know. And thanks very much for the feedback, Malcolm and Jacob. Ian and I are digesting it now. --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: Visual recognition of Django website
On Sep 21, 2007, at 2:22 PM, SmileyChris <[EMAIL PROTECTED]> wrote: > > On Sep 19, 11:44 pm, Ned Batchelder <[EMAIL PROTECTED]> wrote: >> Now we just need to get someone to put it on the site... > > +1. Easy to do, looks good. +1. It's excellent. --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Django Trac signup broken?
In reviewing bug #5579 (see http://code.djangoproject.com/ticket/5579), I discovered I never receive the confirmation email from Trac at http://www.djangoproject.com/accounts/register/. I've tried four times since Sunday, using two email addresses in different domains. I can't actually verify that Trac is mistakenly sending from "[EMAIL PROTECTED]" because I never get the email, and my hunch is it's not being sent. Otherwise I'd see that it was spam-filtered by one of my ISPs. Has anyone succeeded in creating an account at http://www.djangoproject.com/accounts/register/ since the servers moved to new hosting? --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: Django Trac signup broken?
On Sep 26, 8:38 am, Barry Pederson <[EMAIL PROTECTED]> wrote: > Matt Boersma wrote: > > In reviewing bug #5579 (seehttp://code.djangoproject.com/ticket/5579), > > I discovered I never receive the confirmation email from Trac at > >http://www.djangoproject.com/accounts/register/. I've tried four > > times since Sunday, using two email addresses in different domains. I > > can't actually verify that Trac is mistakenly sending from > > "[EMAIL PROTECTED]" because I never get the email, and my hunch is > > it's not being sent. Otherwise I'd see that it was spam-filtered by > > one of my ISPs. > > Yeah, it's currently using "[EMAIL PROTECTED]" as the SMTP FROM > address. My SMTP server refused it with: "sender verify fail for > <[EMAIL PROTECTED]>: Unrouteable address" I tested again today and of course never got the email since our SMTP server must have rejected the bogus sender address. I've used up all my spare email addresses testing this, so I'm done with it. Trac signup has been broken for two weeks now. Until #5579 is fixed, no one new can sign up to help 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?hl=en -~--~~~~--~~--~--~---
Re: Django Trac signup broken?
That fixed it--I got the confirmation email immediately this time after registering. I'll close #5579. Thanks, Jacob. On Oct 1, 2:20 pm, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]> wrote: > OK, it should be fixed for real this time -- emails are now being sent > from "[EMAIL PROTECTED]" > > Matt, can you test, verify, and close the ticket if it works? > > Thanks, > > 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?hl=en -~--~~~~--~~--~--~---
Re: Oracle slicing and backend refactor
On Oct 3, 6:23 am, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > Oracle changes on the queryset-refactor branch are probably going to be > about the last thing to land on that branch because it's very time > consuming to test and work with for me. It sure is--we tend to run only single tests during the day, and the entire suite (against all backends) nightly via a cron job. If there's any help with Oracle testing or coding we could provide on the queryset-refactor branch, please don't hesitate to ask. --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
