Re: GeoDjango and Postgresql

On Nov 9, 6:25 am, Paul McMillan wrote: > I opened #14527 a while ago, but it hasn't gotten much > attention.http://code.djangoproject.com/ticket/14527 > > It would fix the docs which claim that PostGIS doesn't support PostgreSQL 8.4. > > Can I get some GeoDjango users to

Possible thread-safety regression for sitemaps in r13980

After r13980, GIS sitemaps were broken, and when attempting to fix I had questions about the underlying implementation of the changeset: http://code.djangoproject.com/changeset/13980/django/trunk/django/contrib/sitemaps/views.py In the loop iterating over the `sitemaps` argument (L12), the

Re: importing fixtures to postgres fails to set sequences correctly

> > there seems to be a problem with django postgres backend, when > > importing data from fixtures. Data are imported correctly, but the > > sequences for primary keys are set incorrecly on models that have > > generic.GenericRelation field. See example: I have similar code, and was griping in

Re: Thanks for all the hard work

> Thank you very much for all the hard work that you've put in to > Django.  It makes a big difference to web developers to have a > framework that is so well made, so well thought out and so well > documented.  It's a pleasure working with Django, and I'm looking > forward to working with it for

Re: Oracle/GIS Testers Needed

> For GIS I'm fairly certain that's broken, however I'm not quite setup > for running the GIS tests yet, therefore if you're set up for it and > can run the tests please just reply with your tracebacks here > (preferably with them on a pastebin like paste.pocoo.org though :)) > and I'll try to

Re: new Open Layers map widget for use in/out of admin

Charlie, > I would be quite appreciative of any feedback or testing.  My dream, > like anyone else's, is to get it into trunk eventually. :)  That will > require more work, such as whatever is necessary to hook the widget into > forms.ModelForm subclasses, and better documentation and tests.  If

Re: Dallas 1.1 sprint - dates?

On Apr 3, 9:50 am, Jeremy Dunck wrote: > Gary, Justin? > The 17th option is better for me, but at this point it's still not looking like I'll be able to make it. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the

Re: GeometryField doesn't honor the required attribute

> I hope I made myself clearer this time. Opinions please? If this > should be fixed, and I seriously think it must, I'll open a ticket and > attach a patch. I see what you're talking about now, and I agree it's a bug. Please open up a ticket and we'll consider the design decisions there.

Re: GeometryField doesn't honor the required attribute

On Mar 25, 12:20 pm, Fidel Ramos wrote: > My proposed solution would be to call Field's clean() instead of > checking self.null. Isn't the checking of `self.null` that you've identified as the problem already in the `GeometryField.clean` method? Are you proposing a

Re: Reminder: Django 1.1 beta this week means feature freeze

> GIS is a bit of a special case; Justin Bronn is the maintainer there, > and he and the rest of the GeoDjango contributors develop somewhat > independently of the rest of Django. > > That said, they don't get any special exemptions in terms of timeline, > so GeoDja

Re: Filtering with respect to a related objects field

> Is there a way that default managers can be taken into > consideration when filtering through related fields?  I don't know > exactly how this is supposed to work, is this the desired behavior? > It's not a bug, it's a feature :) Specifically, it's an artifact from the 'fix' in #7666 --

Re: #7210 - F() Query Expressions

> The main issue I flagged to Russell in some code review notes was > whether the code needed to be able to handle get_placeholder() output, > instead of hard-coding "%s" everywhere for parameters. If there were > particular column comparisons that required a more massaged approach to > getting

Re: #7210 - F() Query Expressions

> 2) F() expressions have not been updated to work with GIS fields. > However, based on some initial discussions with Justin, it should be > possible to make these changes without affecting any public API. If > anyone with access and experience with contrib.GIS cares to help out > on this front,

Re: #3566 Aggregations: Call for testing

> Refactoring Query.convert_values() into the backend operations would > remove some code duplication, and would also serve to keep all the > data coercion/typecasting code in a common location rather than > spreading some of it into the Query class. However, there are two > things that prevented

Re: Aggregation branch fails with GIS models.

> I'll be looking into this, this week. > Good news is: So far so good (But I haven't tried to mix geo aggregates with > new aggregates yet). OK, in the GeoDjango 1.1 mercurial [1], I've merged in Russell's aggregation branch and modified the aggregate geographic methods to internally use the

Re: Aggregation branch fails with GIS models.

Ariel, > Is it a gis issue or an aggregation one? As I indicated in private correspondence, this was a matter of updating GeoQuery.get_columns to reflect Russell's aggregation changes. I've attached to #3566 a patch for Russell's git repo that fixes the problem (geoquery_aggregation_fix.diff).

Re: Dropping Python 2.3 compatibility for Django 1.1

+1. Eliminates a ton of compatibility code, e.g., no more carrying around a three thousand line Decimal implementation. -Justin --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to

Re: ANN: Django 1.0.1 released

> This:http://code.djangoproject.com/ticket/9613seems to be of the > same vein.  I haven't confirmed it however. Yeah I confirmed it. I went through the contrib apps one-by-one to see if anything else was missing. In addition to auth's missing files, the templates for formtools are omitted.

Re: ANN: Django 1.0.1 released

> I didn't know MANIFEST.in needed data directories listedI know from bug > fixing in setup.py that it generates a list of data files to pass into setup > -- I wonder what that is used for?  I guess it's for install but not > distribution tarfile building? Neither did I -- and those files

Re: ANN: Django 1.0.1 released

> Thanks, I eventually figured this out on my own -- it was the > problem.  Fixed in r9473 and r9474. > I wish I had known about MANIFEST.in sooner, is there any way we re- tag and re-release 1.0.1 with the missing files? Or am I forced to instruct GeoDjango users to avoid easy_install until

Re: ANN: Django 1.0.1 released

> The reason is that MANIFEST.in doesn't tell setuptools to include those > directories in the distribution. Thanks, I eventually figured this out on my own -- it was the problem. Fixed in r9473 and r9474. -Justin --~--~-~--~~~---~--~~ You received this message

Re: ANN: Django 1.0.1 released

> (and obviously I meant 'setup.py sdist') > I don't know how setup.py bundles a tarball, but it's doing it wrong -- GeoDjango is broken in the 1.0.1 release tarball. In particular, at least the following directories were completely _omitted_ from this release:

Re: Google maps subclass of GeoModelAdmin

> I suppose I can log both a ticket and place it on djangosnippets.org. > Thanks This has come up a few times in #geodjango, and I've already written an example on how to use Google's base layer in the admin. I distilled it to a few snippets: http://www.djangosnippets.org/snippets/1144/ It's

Re: Oracle testing wanted

> Oracle is free for non production use. Sort of -- there are some limitations, e.g., you aren't allowed to develop GPL-licensed using their 'free' license. > but you did want to know why none of the core devs > have Oracle installed :) I have the dev version installed on a Windows VM, and the

Re: Pickling QuerySets

> Am I missing where this is discussed, or is it an oversight, or is there > a reason not to mention it?  I'll patch the docs if you'd like... Ned, Malcolm documented this behavior after qs-rf merged. However, this section may have slipped through the cracks with the documentation refactor.

Re: Oracle IntregrityError and get_or_create test case

Matt, FYI, r8471 fixed my problems and all Oracle GeoDjango tests pass again. Thanks. -Justin --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to

Re: You've broken Oracle

> 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

Re: You've broken Oracle

> 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

Re: #7666: Default managers should not restrict access to single related objects

> I forgot to note before, I've added a patch to #7666 which uses James' > suggestion of a pristine QuerySet. Using a "pristine" QuerySet is a bad assumption to make, especially for those who are using custom managers to properly generate SQL for non-standard columns, e.g., geometries. The

Re: GIS: support for Points (markers) in Google Maps

> I could clean this up as a patch to the GIS branch, but there seems to > be some confusion as to whether such functionality should be in the > core product. > > What is the right way forward here? > File a ticket with your patch -- I'm +1 because it doesn't make sense to support GPolygon and

Re: Django releases

> That aside, now that QSRF is   > getting a real fleshing-out and all these reports are trickling in, I   > think it would be a bad idea to stamp a version right now until either   > someone can step up and fill Malcolm's shoes as a queryset maintainer,   > or he becomes available once again

Re: Django releases

For the record, I'm -1 on releasing 1.0 without NFA. As I've discussed with Jacob and Adrian, GeoDjango will be merged with trunk at some point in the future. In my opinion, there's nothing preventing it from being included in the 1.0 release (I'm currently addressing the biggest hurdle,

Re: Interaction between [Multiple]ModelChoiceField and its widget

> Also, when the number of choices is big, none of the provided widgets > are very usable, so I have for instance created a TreeSelect widget > which groups choices into categories (columns in the table) and > displays them in a tree whose branches are collapsible (see an example > at [1]).  But

Re: PostgreSQL 8.3 and casting

> I see that the Oracle backend already includes > OracleQueryconvert_values which does conversion into the backend based > on the the passed value and the field type. > > Perhaps we need to add that for PostgreSQL now?  It's pretty onerous > to do the casting at the app level. > The

Re: Maybe DEBUG=True should only record the last N SQL queries?

> What do people think of having the debug SQL log limited to only > storing the last N queries, with N set to something sensible like 200 > by default? This behavior could be controlled by a setting so if > people want to log everything they can: > > DEBUG_SQL_LOG_LIMIT = 200 # Set to 0 to

Re: Changeset 7427

> I bet Oracle is broken in qs-rf. Yeah, Malcolm opened up #7036 two days ago in response to errors reported by Ian Kelly. I've attached a patch. The problem had to do with `resolve_columns` not taking into account that extra select SQL is in a different position due to changes in #7340. The

Re: Public spec is needed for writing ORM adapters

Alex, Antonio, & Leon: IBM should understand our frustration when a spec exists (in `django.db.backends`) but, because it is in source code form, your particular IBM department cannot look at it. Thus, IBM is attempting to shift the burden onto our community to produce onerous technical

Re: New field lookups

Julian, The django-developers mailing list for discussing the development of Django itself; django-users is the appropriate forum for this type of question. There are no lookups for hour, minute, second because this functionality may be accomplished by utilizing a `range` lookup with Python

Re: Future-proofing django.template (and elsewhere) against circular imports

> I'm *way* off base at the moment (and stuck gradually walking towards > HEAD, fixing my patch in increments; this is where git definitely has an > advantage over hg, but I'm using the latter). I've found hg-svn to be particularly useful in helping me pull changes from the various SVN Django

Re: Proposal: deprecated Model.__init__(*args)

I'm +1 for deprecating positional arguments from __init__(). > Relying on the order of fields in the model definition is asking for a > heaping load of fail. Hence my desire to see it go away. While I agree this argument applies for having positional args in __init__(), those instantiating

Re: Extending Django in a production-oriented way. Is it possible?

> 2. '%s' placeholders are hardcoded into Django. Existing solutions > (like in sqlite backend) introduce the unneeded overhead in each > database query. There are many other small things hardcoded into > Django with Postgres in mind. Other backends has workarounds with > added overhead and it

Re: Bug #1443 / Dates prior to 1900 Potential Patch

I added your patch to the ticket. It's much easier to submit attachments, etc. when you register: http://www.djangoproject.com/accounts/register/ Regards, -Justin --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups

Re: GeoDjango--no "django_session_id_seq" with pgsql?

Matt, First, a question of this sort is better suited to django-users, as django-dev django-dev is for discussion of the development of Django itself. Second, from what I can tell db_dump.py is not part of the official trunk -- thus I'm not familiar with it. My priority is to have

Re: GeoDjango: ST_Transform broken (no SRID on first arg)?

Matt, I'm having difficulty reproducing this error, as the objects I create from the admin save ok. Can you provide the code for your model and/or a more verbose traceback? Are you using psycopg2? Have you modified any parts of the code, especially any GEOS components? I ask because the GEOS

Re: GeoDjango installation instructions correction?

> If I am understanding things correctly, GeoDjango uses ST_* functions in > PostgreSQL, but these functions weren't added until 1.2.1. I started developing GeoDjango when PostGIS 1.2.1 was the latest. I believe PostGIS began adding the ST_* routines in 1.2.1, and in 1.3.1 they deprecated any

Re: query.py refactoring by Malcolm: status?

I'm interested in the status too, and I'm willing to help out w/any implementation. I've got a few feature requests for this refactor; specifically, the possibility of mainlining several of the modifications I've made in the GIS branch that assist in constructing spatial SQL. -Justin

Re: Ticket #399 (Bigint field object needed) status

+1 to bigint support. I ran into this problem recently when implementing IP geolocation models. I know I'm not the only one that has or will experience these problems (remember when slashdot crashed after 16,777,216 comments?). >From what I understand, the largest hurdle to having large

Re: db2 backend

I have no experience with DB2, but I'm interested in a backend for Django. Specifically, my interest stems from DB2's spatial database offering ("Spatial Extender") that is free and feature complete (OGC compliant). Oracle and ArcSDE have high licensing fees, and MySQL's spatial support is

Re: lazy-geometries/planning

> For instance, the lazy geometries patch in 4322 is way off > track now we have support for ogr geometries. The lazy geometries patch in 4322 is only a month old, and ten days ago I incorporated portions of your patch in r5448. Not exactly what I would consider "way off track" -- at least from

Re: GSoC 2007: Check Constraints Update

Thejaswi, > Problem: > The check constraints got added successfully (after a syncdb) but the > problem is when I go to the admin page and to the model's page in it, > I get an error ... This error vanishes when I comment the check fields > in the models.py. I don't understand why the Check

Re: Custom field _post_create_sql()

> In PostGIS, the AddGeometryColumn() function needs to be run separately > after the create table. It adds the geometry field to the table, adds > its definition (projection, geometry type, dimensions) to the > 'geometry_columns' table, creates a number of constraints, etc. Thanks, Rob, for the

Re: GSoC 2007: Implementing Check Constraints

>I am a participant in the Summer of Code 2007. Welcome to the development list! >For my project,all that I have to do is actually append the sql >statements for the table (containing the check statements) when syncdb >is called. My problem is a typical one that "There is more than one >way of

Re: Type coercion in Django

> How do you handle data input of GIS types? What format is used during > assignment? During assignment, PostGIS returns in a format called HEXEWKB (hereinafter "HEX"), one of its 'canonical forms'. Essentially it's a hexadecimal string of the binary format (WKB, an OGC standard). For input