Re: Weekly check-in (this should be #5, right...?)

[akaariai]

On Jul 6, 1:39 am, akaariai  wrote:
> Having said all this, for this project "extend the connection tuple"
> approach seems to be the only sane choice.

I implemented this in my github branch 
https://github.com/akaariai/django/tree/composite_join

With this you can do:
a = Article.objects.all()
a.query.get_initial_alias()
a.query.join(('basic_article', 'foo', ('pk_part1', 'pk_part2'),
('foo_pk_part1', 'foo_pk_part2')), promote=True)
print a.query
SELECT "basic_article"."id", "basic_article"."headline",
"basic_article"."pub_date" FROM "basic_article" LEFT OUTER JOIN "foo"
ON ("basic_article"."pk_part1" = "foo"."foo_pk_part1" AND
"basic_article"."pk_part2" = "foo"."foo_pk_part2")

The connection parameter is now a tuple (lhs, table, (lhs_col1,
lhs_col2, ...), (col1, col2, ...)). This seemed to be the way of least
pain.

All current test are passed on sqlite3. There will probably be
problems when more complex queries are tried with multi-column join
conditions. I hope this gives at least an idea how to approach the
multi-column outer joins problem.

 - Anssi

-- 
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: Weekly check-in (this should be #5, right...?)

[akaariai]

On Jun 27, 4:22 am, Michal Petrucha  wrote:
> some visible progress on my project at long last. I spent most of the
> last week digging deep inside the ORM's entrails to make composite
> field lookups possible and finally it looks promising.
>
> While working on this I found out the extra_filters approach I
> intended to use was a dead end (which reminded me of what Russ wrote
> in response to my proposal: "I'm almost completely certain you'll
> find some gremlin lurking underneath some dark corner of the code").

I did a glance-over of your github branch. I was especially looking
for how you will handle LEFT OUTER JOINS involving composite primary
keys / foreign keys. If I am not missing something, I think this
haven't been done yet. I have myself been thinking about this issue,
and I thought it would be good to share what I have found out.

The problematic part for multi-column join conditions is in
django.db.models.sql.query:
def join(self, connector, ...):
"""
Returns an alias for the join in 'connection', either reusing an
existing alias for that join or creating a new one. 'connection'
is a
tuple (lhs, table, lhs_col, col) where 'lhs' is either an existing
table alias or a table name. The join correspods to the SQL
equivalent
of::

lhs.lhs_col = table.col
"""

Obviously this can not work for creating multi-column joins.

The connection information is stored in alias_map, join_map and
rev_join_map. In particular, in alias_map is stored (table, alias,
join_type, lhs, lhs_col, col, nullable). Currently the contents of the
alias_map is turned into SQL (sql/compliler.py, get_from_clause()) as:

result.append('%s %s%s ON (%s.%s = %s.%s)'
% (join_type, qn(name), alias_str, qn(lhs),
 qn2(lhs_col), qn(alias), qn2(col)))

The most simple way to extend this to contain more columns would
probably be the following:
 - connection is defined as (lhs, table, lhs_col1, col1, lhs_col2,
col2, ...)
 - alias_map format needs to change a bit so that the extra columns
can be stored in there. One could store the extra column after the
nullable. Cleaner would be to have the columns in one tuple: (table,
alias, join_type, lhs, (cols), nullable)
 - Limited amount of places needs to be fixed, most notably the
get_from_clause() of compiler.py

The downside of the above is that it does not support any other join
conditions than ones involving 2 tables and a list of anded columns.
For composite fields this is enough.

For future usage it would be nice if one could pass in Where nodes as
the connection. This would allow for arbitrary join conditions. The
Where node knows how to turn itself into SQL, how to relabel aliases
and so on. This approach has some problems, however:
  - How to generate the Where node?
  - How to match existing joins to new joins? Currently this is done
by checking that the connection four-tuple is equivalent to the
existing join's four tuple. I don't think Where nodes know how to
check equivalence to another node. And even if where nodes knew how to
do that, also all the leaf nodes would need to know how to do that.
  - Performance issues, cloning a Where node is more expensive than
cloning a tuple. Also construction, equivalence checking and other
operations too are somewhat more expensive than using tuples.
  - Overkill for composite fields

Of course, the approaches could be combined, that is you pass in the
join condition as a tuple, and you can pass extra_filters (default
None) as a Where node. This would keep the normal case efficient but
allow for more complex join conditions if really needed. The join
having extra_filters could not be reused, except when explicitly
stated.

Having said all this, for this project "extend the connection tuple"
approach seems to be the only sane choice.

The work you have done looks very promising. I hope this post has been
at least somewhat useful to you.

 - Anssi

-- 
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: [GSoC form-rendering] Weekly Check-in

[Gregor Müllegger]

Hi, Chris.

Seems that I'm now unemployed as GSoC Student,
looks like you already did all the work! ;-)

Besides this, great work. If I understand the source code right (haven't run
it yet), then it's already feature complete, isn't it?

I also like the idea of "extends", I will definitely bring this up to Carl's
attention. I don't know if it's in the core devs taste to change the meaning
of a {% block %} slightly in the context of a form tag.

I try to keep you posted.


2011/7/5 Chris Beaven :
> Hi Gregor, I've just put up a new version of django-forms [1] which 
> implements a similar version of the proposal with the main difference being 
> "extends". Take a look.
>
> 1. https://github.com/SmileyChris/django-forms

-- 
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: django tests fails!

[Russell Keith-Magee]

On Tue, Jul 5, 2011 at 9:01 PM, Mateusz Harasymczuk  wrote:
> #urls.py
>     url(r'^', include('rm.urls', namespace="rm"), name="rm"),
> #rm/urls.py
>     url(r'progress/$', ProgressView.as_view(), name='progress'),

Ok -- seriously -- I have no interest in playing hunt the bug.

If you want to report a bug, then you need to provide *clear*
instructions on how to reproduce the bug.

You have provided:
 * Evidence that when you run some undeclared project that includes
contrib.messages, that there are failures in your test set.
 * One line from 2 different urls.py files.

Consider this from my position. I know *nothing* about what it is you
are trying to do. You haven't provided any details on how the various
parts you have provided fit together. Do I have enough information to
reproduce the problem you are having?

Until I have enough information to reproduce your problem, I can't
help you -- and neither can anyone else.

What would be helpful at this point is one of the following:
 1) A diff against *Django's* test suite that introduces a new failing
test demonstrating the problem you have found, or
 2) A *minimal* sample project that demonstrates the problem. Not a
dump of your entire codebase -- a project with 1 url, and one lookup,
and one tests -- the simplest possible project that demonstrates your
problem.

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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: django tests fails!

[Mateusz Harasymczuk]

#urls.py
url(r'^', include('rm.urls', namespace="rm"), name="rm"), 

#rm/urls.py
url(r'progress/$', ProgressView.as_view(), name='progress'),

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/rzSmmSfi9VkJ.
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: django tests fails!

[Mateusz Harasymczuk]

> python manage.py test
Creating test database for alias 'default'...
E...E..E.
==
ERROR: test_middleware_disabled 
(django.contrib.messages.tests.cookie.CookieTest)
--
Traceback (most recent call last):
  File 
"C:\Python27\Lib\site-packages\django\contrib\messages\tests\base.py", line 
251, in test_middleware_disabled
data, follow=True)
  File "c:\Python27\lib\unittest\case.py", line 471, in assertRaises
callableObj(*args, **kwargs)
  File "C:\Python27\Lib\site-packages\django\test\client.py", line 455, in 
post
response = super(Client, self).post(path, data=data, 
content_type=content_type, **extra)
  File "C:\Python27\Lib\site-packages\django\test\client.py", line 256, in 
post
return self.request(**r)
  File "C:\Python27\Lib\site-packages\django\test\client.py", line 387, in 
request
response = self.handler(environ)
  File "C:\Python27\Lib\site-packages\django\test\client.py", line 84, in 
__call__
response = self.get_response(request)
  File "C:\Python27\Lib\site-packages\django\core\handlers\base.py", line 
169, in get_response
response = self.handle_uncaught_exception(request, resolver, 
sys.exc_info())

  File "C:\Python27\Lib\site-packages\django\core\handlers\base.py", line 
218, in handle_uncaught_exception
return callback(request, **param_dict)
  File "C:\Python27\Lib\site-packages\django\utils\decorators.py", line 91, 
in _wrapped_view
response = view_func(request, *args, **kwargs)
  File "C:\Python27\Lib\site-packages\django\views\defaults.py", line 31, in 
server_error
return http.HttpResponseServerError(t.render(Context({})))
  File "C:\Python27\Lib\site-packages\django\template\base.py", line 124, in 
render
return self._render(context)
  File "C:\Python27\Lib\site-packages\django\test\utils.py", line 66, in 
instrumented_test_render
return self.nodelist.render(context)
  File "C:\Python27\Lib\site-packages\django\template\base.py", line 747, in 
render
bits.append(self.render_node(node, context))
  File "C:\Python27\Lib\site-packages\django\template\debug.py", line 73, in 
render_node
result = node.render(context)
  File "C:\Python27\Lib\site-packages\django\template\loader_tags.py", line 
127, in render
return compiled_parent._render(context)
  File "C:\Python27\Lib\site-packages\django\test\utils.py", line 66, in 
instrumented_test_render
return self.nodelist.render(context)
  File "C:\Python27\Lib\site-packages\django\template\base.py", line 747, in 
render
bits.append(self.render_node(node, context))
  File "C:\Python27\Lib\site-packages\django\template\debug.py", line 73, in 
render_node
result = node.render(context)
  File "C:\Python27\Lib\site-packages\django\template\loader_tags.py", line 
64,in render
result = block.nodelist.render(context)
  File "C:\Python27\Lib\site-packages\django\template\base.py", line 747, in 
render
bits.append(self.render_node(node, context))
  File "C:\Python27\Lib\site-packages\django\template\debug.py", line 73, in 
render_node
result = node.render(context)
  File "C:\Python27\Lib\site-packages\django\template\loader_tags.py", line 
64, in render
result = block.nodelist.render(context)
  File "C:\Python27\Lib\site-packages\django\template\base.py", line 747, in 
render
bits.append(self.render_node(node, context))
  File "C:\Python27\Lib\site-packages\django\template\debug.py", line 73, in 
render_node
result = node.render(context)
  File "C:\Python27\Lib\site-packages\django\template\base.py", line 1008, 
in render
return self.nodelist.render(new_context)
  File "C:\Python27\Lib\site-packages\django\template\base.py", line 747, in 
render
bits.append(self.render_node(node, context))
  File "C:\Python27\Lib\site-packages\django\template\debug.py", line 73, in 
render_node
result = node.render(context)
  File "C:\Python27\Lib\site-packages\django\template\defaulttags.py", line 
449, in render
raise e
TemplateSyntaxError: Caught NoReverseMatch while rendering: u'rm' is not a 
regis
tered namespace

==
ERROR: test_middleware_disabled 
(django.contrib.messages.tests.fallback.FallbackTest)
--
Traceback (most recent call last):
  File 
"C:\Python27\Lib\site-packages\django\contrib\messages\tests\base.py", line 
251, in test_middleware_disabled
data, follow=True)
  File "c:\Python27\lib\unittest\case.py", line 471, in assertRaises
callableObj(*args, **kwargs)

Re: django tests fails!

[Russell Keith-Magee]

On Tue, Jul 5, 2011 at 8:38 PM, Mateusz Harasymczuk  wrote:
> I am sorry, my bad.
> I was not sure that this one is a bug too, therefore I have asked at
> django-users:
> https://groups.google.com/forum/#!topic/django-users/S_4IuKw_e2U
>
> however I think it is, and it should be reported to trac.
> What do you think?

Well, without code for a specific test case that is failing, I can't
comment. There are certainly plenty of tests that validate that
namespaced URLs and URL reversing works -- see the
regressiontests/urlpatterns_reverse directory. If you can narrow this
down to a specific case that is failing, then yes, it should be opened
as a ticket.

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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Raising the minimum PostgreSQL version to 8.3

[Russell Keith-Magee]

On Thu, Jun 30, 2011 at 7:33 PM, Anand Kumria  wrote:
> Hi,
>
> In ticket #16255 ,
> changeset https://code.djangoproject.com/changeset/16423 raises the
> minimum supported PostgreSQL version to 8.2
>
> However the PostgreSQL support policy,  wiki/PostgreSQL_Release_Support_Policy>, indicates that 8.2 will be
> end-of-life at the end of the 2011
>
> I think it would be better to raise the documented minimum version to
> 8.3 (EOL is in 2013). Actually modifying Django to take advantage of
> features available in 8.3 (or later) could be done at another time
> though.
>
> Should I re-open the ticket to indicate this, send in a patch for this
> doc. change, or is this email enough?

Hi Anand,

I'll fully acknowledge that PostgreSQL 8.3 is better than 8.2, but I'm
not aware of any feature in Django that hinges on support of 8.3, or
any plans to introduce such a feature.

On top of that, 8.2 isn't deprecated *yet*, and I would like to think
that we could get Django 1.4 out the door before the end of 2011, so
we'd be deprecating a version of PostgreSQL slightly before it is
EOL'd, without any pressing technical need. "Because we can" isn't a
good enough reason to deprecate something in my opinion, because in a
community as large as Django's, every deprecation affects somebody.

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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: django tests fails!

[Mateusz Harasymczuk]

I am sorry, my bad.

I was not sure that this one is a bug too, therefore I have asked at 
django-users:
https://groups.google.com/forum/#!topic/django-users/S_4IuKw_e2U

however I think it is, and it should be reported to trac.
What do you think?


-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/EGl6rLU2vQEJ.
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: django tests fails!

[Russell Keith-Magee]

On Tue, Jul 5, 2011 at 6:52 PM, Mateusz Harasymczuk  wrote:
> I have found two bugs in tests django.contrib.auth
> https://code.djangoproject.com/ticket/16412
> https://code.djangoproject.com/ticket/16413

Hi Mateusz,

Thanks for opening those tickets, but as it says in the contributions
guide, there's no need to post to django-dev to tell us that you've
opened at ticket. Updates to tickets are posted to a separate
django-updates mailing list, so anyone who wants to know about new
tickets will be notified via that channel.

[1] https://docs.djangoproject.com/en/1.3/internals/contributing/#reporting-bugs

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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: ImportError: No module named sh_csv_importer

[Karen Tracey]

Please ask questions about using Django on django-users. The topic of this
list is the development of Django itself.

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.

ImportError: No module named sh_csv_importer

[prabesh shrestha]

I am trying to run a project in Django that was coded 3-4 years
before. I have installed most of the modules required by the project
but could not locate one of the module required to run the project. I
am getting

ImportError: No module named sh_csv_importer

I have tried to search it , installed it through easy_install and
pip , with no luck.I am using python 2.6.1 and django 1.2 currently in
my system.

-- 
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.

django tests fails!

[Mateusz Harasymczuk]

I have found two bugs in tests django.contrib.auth

https://code.djangoproject.com/ticket/16412
https://code.djangoproject.com/ticket/16413

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/Vg15tT63Y6MJ.
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: Reversing translated urls in templates

[Stephen Kelly]

Jannis Leidel wrote:

> 
> On 05.07.2011, at 09:26, Jonathan Slenders wrote:
> 
>> I'm also +1 on {% language lang_code %}... {% endlanguage %}
>> 
>> We are using exactly this template tag for maybe about half a year
>> already. Not for i18n urls, but for formatting numbers. The decimal
>> separator in Dutch is a comma, but sometimes we want to be sure to
>> have a dot a some part of the template. (When rendering SVG, JSON or
>> other markup lanugages.)
>> 
>> So, this is certainly a very versatile approach.
> 
> Great, thanks all for your opinions, I actually went ahead yesterday
> and added it in https://code.djangoproject.com/changeset/16501
> 
> Jannis
> 

Isn't this about more than language, but also locale?

In Grantlee I implemented this as a with_locale tag:

http://gitorious.org/grantlee/grantlee/blobs/master/examples/contacts/themes/linguist/sleepy/main.html

And then eg dates are also localized:

http://steveire.files.wordpress.com/2010/11/contacts_multi_lang_headers.png




-- 
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: Django Design Czar

[Idan Gazit]

Hey Victor,

So far, only small steps -- my time hasn't provided for any thing "major" 
yet. :)

My twitter will be a good place, as will this list. Right now, my head is 
mainly in helping out with a couple of specific issues (formrendering, admin 
sorting). There are some plans underway to provide better places to get 
involved/contribbute if you're into that sort of thing, as well as tracking 
progress of contributions that aren't easily quantifiable like code.

Cheers!

-I

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/Kw09rJtoc8UJ.
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: Reversing translated urls in templates

[Jannis Leidel]

On 05.07.2011, at 09:26, Jonathan Slenders wrote:

> I'm also +1 on {% language lang_code %}... {% endlanguage %}
> 
> We are using exactly this template tag for maybe about half a year
> already. Not for i18n urls, but for formatting numbers. The decimal
> separator in Dutch is a comma, but sometimes we want to be sure to
> have a dot a some part of the template. (When rendering SVG, JSON or
> other markup lanugages.)
> 
> So, this is certainly a very versatile approach.

Great, thanks all for your opinions, I actually went ahead yesterday
and added it in https://code.djangoproject.com/changeset/16501

Jannis

-- 
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.

[GSoC composite fields] Weekly check-in #6

[Michal Petrucha]

Hi folks,

Sorry about this delayed post. My repo now supports using
CompositeField as a model's primary key, as far as models are
concerned, that means, Model.pk and friends.

For the next week, expect admin to work. THe work is underway, nothing
worthy of publishing just yet.

Michal

[1] https://github.com/konk/django


signature.asc
Description: Digital signature

Re: Reversing translated urls in templates

[Jonathan Slenders]

I'm also +1 on {% language lang_code %}... {% endlanguage %}

We are using exactly this template tag for maybe about half a year
already. Not for i18n urls, but for formatting numbers. The decimal
separator in Dutch is a comma, but sometimes we want to be sure to
have a dot a some part of the template. (When rendering SVG, JSON or
other markup lanugages.)

So, this is certainly a very versatile approach.

-- 
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.