ctually
> using the db cache isn't!).
If someone is going to commit fixes to the DB cache backend, please
also take a look at <http://code.djangoproject.com/ticket/11483>
(which is causing failures with Jython backends).
--
Leo Soto M.
http://blog.leosoto.com
--~--~-~--~~-
__getattr__() to delegate attribute acces from one
model to the other? (if that's the central problem).
--
Leo Soto M.
http://blog.leosoto.com
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers&
the bug description or patch, as
always I'll be happy to help.
Regards,
[1] http://code.djangoproject.com/ticket/11621
--
Leo Soto M.
http://blog.leosoto.com
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"D
n move them all to count(id_col), which is faster).
Just curious: In which backends is count(id_col) faster than count(*)?.
I'd say that any decent database engine should take both as the same
(as long as a PK exists and no outer joins are performed), but I could
be wron
ackend would do.
No, you still need to manage the differences between SQL dialects.
--
Leo Soto M.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send e
m trying run syncdb.
I'll post my changes (well, hacks) against the Django svn codebase as
soon as I can.
--
Leo Soto M.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to
bigger than 32KBytes), but at least nothings seems broken
when running it on regular python.
--
Leo Soto M.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group,
o do some
exploratory work. Anyway, if people here thinks otherwise, I have no
problem on filling tickets with the changes.
--
Leo Soto M.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers"
uld write something like:
db_values = [connection.adapt_field_value(f, self) for f in non_pks]
Am I on the right track? Do you people have other ideas?
--
Leo Soto M.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
&
; has the same functionality just had a quick look.
Thanks, it looks possible to solve this problem with a custom DataHandler.
Although it's not a direct conversion path (datetime -> string ->
java.sql.TimeStamp), it has the benefit that doesn't mess with
On 9/19/07, Leo Soto M. <[EMAIL PROTECTED]> wrote:
> I'm working on the splitting [...]
Well, I did it, see: http://code.djangoproject.com/ticket/5546
Please, if someone is currently working on such tests, ping me so I
can update the split version and post another patch. Or w
On 9/19/07, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
>
> On 9/19/07, Leo Soto M. <[EMAIL PROTECTED]> wrote:
> > Well, I did it, see: http://code.djangoproject.com/ticket/5546
>
> Committed in [6379] -- thanks a bunch for the grunt work. The length
> of t
ke easy to fake
the remote address when using that middleware. If people are _really_
using more than one trusted proxy (a transparent Squid getting in the
way maybe?), the middleware could have a settings to let the user
indicate how many values of X-Forwarded-For are know to be good.
--
Leo Soto
e proxying
> rather than proxying
The middleware is about reverse proxying too. According to the doctests:
"[...] if you're not behind a reverse proxy that sets
HTTP_X_FORWARDED_FOR automatically, do not use this middleware"
--
Leo Soto M.
--~--~-~--~~~---~--~
ase for reverse proxy users who want
to have a *reliable* remote address is not even hard: is impossible.
No documentation can fix it.
--
Leo Soto M.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django
orwarded_for.split(",")[-NUMBER_OF_TRUSTED_PROXY_SERVERS].strip().
What do you think?
--
Leo Soto M.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email
On 9/20/07, Leo Soto M. <[EMAIL PROTECTED]> wrote:
> Now, if having a reliable remote IP address is important, then a
> setting (NUMBER_OF_TRUSTED_PROXY_SERVERS?) specifying how many values
> you can trust is the only thing that occurs to me. (I'm not that
&g
applied the jython patch to fix the __module__ problems.
>
> and that's about all for major stuff i think.
Cool. Keep up the good work! And file some tickets here when you think
is appropriate.
--
Leo Soto M.
--~--~-~--~~~---~--~~
You received this message
ng
loudly that, *when using this middleware, you can't trust the remote
IP, even if you trust the proxy server*. That's all.
--
Leo Soto M.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers&quo
m trying to write it in
> such a way that it might be useful for other Python frameworks.
Maybe I completely misunderstood you, but what would be the difference
with modjy <http://www.xhaus.com/modjy/>?
--
Leo Soto M.
--~--~-~--~~~---~--~~
You received this mes
majority fails because strptime
is not present on Jython's datetime module]
As I touched many parts of Jython and Django, I'm now organizing all
the bits, to get presentable patches (or bug reports) to both
projects.
--
Leo Soto M.
--~--~-~--~~~---~--~~
You received
rs on the origin server, since they will contain
more than one (comma-separated) value if the original request already
contained one of these headers."
[1]http://wiki.squid-cache.org/SquidFaq/ConfiguringSquid#head-3518b69c63e221cc3cd7885415e365ffaf3dd27f
[2]http://httpd.apache.org/docs/2.2/mod/mod_
does it in jython?
Heh. I'm also having headaches with this behaviour. But people on the
jython-dev mailing list are in a better position to answer this.
--
Leo Soto M.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Goog
Django business.
--
Leo Soto M.
--~--~-~--~~~---~--~~
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 gro
ad up about my broken patch. I didn't made a
full build after doing it, so I didn't realized the problem.
--
Leo Soto M.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To pos
asattr(self, '__unicode__'):
return force_unicode(self).encode('utf-8')
return '%s object' % self.__class__.__name__
The key is the hasattr() check. It's always true on Jython because
__unicode__ is defined on object.
Anyway, I just noticed that the uploaded test case uses the hasattr, s
On 9/25/07, Ian Kelly <[EMAIL PROTECTED]> wrote:
>
> On 9/20/07, Leo Soto M. <[EMAIL PROTECTED]> wrote:
> > Oh, yeah. That's Jython's unicode(foo) calling foo.__str__ even when
> > hasattr(foo, '__unicode__') under some circumstances.
>
> In case you missed it
On 9/25/07, Leo Soto M. <[EMAIL PROTECTED]> wrote:
[...]
> At least on SVN trunk , object.__unicode__ is gone too. So, #5560 is
> no longer needed.
Forget that. object__unicode__ is gone on Jython, but the __unicode__
attribute on the instances is not recognized yet.
So #5560 is
ect module is also not used
> afterwards.
To put it into sys.modules? (Not very useful, but it's the only
side-effect that occurs to me)
--
Leo Soto M.
http://blog.leosoto.com
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the G
On Mon, Mar 24, 2008 at 10:30 AM, Jeremy Dunck <[EMAIL PROTECTED]> wrote:
>
> On Sat, Mar 22, 2008 at 3:04 PM, Leo Soto M. <[EMAIL PROTECTED]> wrote:
> ...
> > On the other hand, all this gymnastic is done to allow receivers which
> > do not conform to the
les
>
> now, you have to write
>
> user has {% if num_files %} {{ num_files }} {% else %} no {%
> endif %} files
It already exists:
{{ num_files|default:"no" }}
--
Leo Soto M.
http://blog.leosoto.com
--~--~-~--~~~---~--~~
You receiv
inate something once I
get the core Django working flawlessly on Jython.
--
Leo Soto M.
http://blog.leosoto.com
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this gro
I see that almost all Field subclasses which implements
get_db_prep_save end calling Field.get_db_prep_save anyway. That's
curious, because Field.get_db_prep_save is a no-op.
Is it just some OOP style which we want to keep?
--
Leo Soto M.
http://blog.leosoto.com
Hello django-devs!
FWIW, I'm forwarding my GSoC weekly report to this list. Any ideas,
comments, flames, etc are welcome.
-- Forwarded message --
From: Leo Soto M. <[EMAIL PROTECTED]>
Date: Sat, May 31, 2008 at 12:00 AM
Subject: GSoC Weekly Report: Django on
On Wed, May 28, 2008 at 5:08 PM, Alex Koshelev <[EMAIL PROTECTED]> wrote:
> On May 29, 12:57 am, "Leo Soto M." <[EMAIL PROTECTED]> wrote:
>> I see that almost all Field subclasses which implements
>> get_db_prep_save end calling Field.get_db_prep_sa
On Tue, May 27, 2008 at 2:50 PM, Jacob Kaplan-Moss
<[EMAIL PROTECTED]> wrote:
>
> On Mon, May 26, 2008 at 11:26 PM, Leo Soto M. <[EMAIL PROTECTED]> wrote:
> > dates, times, and datetimes are converted to string _before_ being
> > passed to the backend.
>
&g
As nobody said anything against forwarding my SoC reports here, I'm
assuming it is OK to continue doing it :)
-- Forwarded message --
From: Leo Soto M. <[EMAIL PROTECTED]>
Date: Fri, Jun 6, 2008 at 11:16 PM
Subject: GSoC Weekly Report (#2): Django on Jython
To: JythonDeve
th zxJDBC. Same
workaround as yours:
https://hg.leosoto.com/django.doj/rev/235b40d3da2e
[1]
http://groups.google.com/group/django-developers/browse_thread/thread/fb1afa93451008a2/0fed055c00cb64e7
[2] https://hg.leosoto.com/django.doj/log?rev=leo.soto+get_db_pr
-- Forwarded message --
From: Leo Soto M. <[EMAIL PROTECTED]>
Date: Sun, Jun 15, 2008 at 11:25 PM
Subject: GSoC Weekly Report (#3): Django on Jython
To: JythonDevelopers <[EMAIL PROTECTED]>
So, I'm a bit late with the weekly report. in part because it has been
a st
On 12 jun, 21:37, "Leo Soto M." <[EMAIL PROTECTED]> wrote:
> On Thu, Jun 12, 2008 at 8:35 PM, Ramiro Morales <[EMAIL PROTECTED]> wrote:
> [...]
>
> > Since then I've opened ticket [2]#7420 with a patch
>
> I see that part of the patch deals with th
that it should be
resolved at the BooleanField level. The anonymous commenter there has
shown that, unless this issue is fixed at the mysql backend level,
values() will continue yielding 0,1 for False,True.
[1] http://code.djangoproject.com/ticket/7190
--
Leo Soto
-- Forwarded message --
From: Leo Soto M. <[EMAIL PROTECTED]>
Date: Mon, Jun 30, 2008 at 12:12 AM
Subject: GSoC Weekly Report (#4 and #5): Django on Jython
To: Jython-Dev Developers <[EMAIL PROTECTED]>
Here is me again, back to doing weekly reports (sorry for miss
django database
backend.
I would appreciate thoughts on the general approach, and some guidance
if I missed something.
[1] http://code.djangoproject.com/ticket/7560
--
Leo Soto M.
http://blog.leosoto.com
--~--~-~--~~~---~--~~
You received this message because you
On Thu, Jul 3, 2008 at 8:27 PM, Russell Keith-Magee
<[EMAIL PROTECTED]> wrote:
>
> On Fri, Jul 4, 2008 at 4:57 AM, Leo Soto M. <[EMAIL PROTECTED]> wrote:
>>
>> Hi all!,
>>
>> I've posted a patch[1] with a small refactor to some Field's
>> get_d
t pushed that logic to DatabaseOperations and named it
"year_lookup_bounds".
So the new posted patch[1] is updated to svn trunk, and also fixes a
test that would broke because get_db_prep* now may return different
values for different backends.
[1]
http://code.djangoproject.com/attachment/
On Fri, Jul 4, 2008 at 12:27 AM, Leo Soto M. <[EMAIL PROTECTED]> wrote:
> So the new [...]
A quick update: After more testing with real django applications I
discovered that I was breaking get_next_by_FIELD. This fourth patch[1]
fixes this issue and includes tests for this use case (whi
-- Forwarded message --
From: Leo Soto M. <[EMAIL PROTECTED]>
Date: Mon, Jul 7, 2008 at 1:08 PM
Subject: GSoC Weekly Report (#6): Django on Jython
To: Jython Developers <[EMAIL PROTECTED]>
Hi again!
Here is my report of what was done on the past week:
-
That also would help to be compatible with other Python VMs, which
don't recognize the PYTHONPATH environment variable (IronPython uses
IRONPYTHONPATH; Jython uses a Java VM property)
--
Leo Soto M.
http://blog.leosoto.com
--~--~-~--~~~---~--~~
You received this
ction.connection.autocommit(True)
> +else:
> +connection.connection.autocommit = True
> elif hasattr(connection.connection, "set_isolation_level"):
> connection.connection.set_isolation_level(0)
As this is also needed for JDBC backends, I filled
/#get-db-prep-lookup-self-lookup-type-value
--
Leo Soto M.
http://blog.leosoto.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-deve
On Tue, Jul 15, 2008 at 12:38 PM, Malcolm Tredinnick
<[EMAIL PROTECTED]> wrote:
>
>
> On Tue, 2008-07-15 at 11:49 -0400, Leo Soto M. wrote:
>> After fixing some corner cases of #7560[1], and realizing that it is
>> too easy to write a wrong get_db_prep_lookup method (ex
On Tue, Jul 22, 2008 at 12:01 PM, Sean Legassick
<[EMAIL PROTECTED]> wrote:
>
>
> On 22 Jul 2008, at 15:01, Leo Soto M. wrote:
>
>> I'm not going to pretend that I know why there is not
>> TimeField.to_python. But some changes on #7560 needed it, so it is
>&g
On Tue, Jul 22, 2008 at 5:29 PM, Sean Legassick
<[EMAIL PROTECTED]> wrote:
> On 22 Jul 2008, at 17:13, Leo Soto M. wrote:
> >
> > > Anything I can do to help? (I do a lot of development with the gis
> > > branch and PostGIS so I can try out the patch
t; and
looks like the complete test suite runs correctly there (I mean,
without spurious errors):
http://testing.ingenium.cl/hudson/job/django-trunk/
--
Leo Soto M.
http://blog.leosoto.com
--~--~-~--~~~---~--~~
You received this message because you are subscribed t
ly thread safe". You know, there
are GIL-less Python implementations out there ;-)
--
Leo Soto M.
http://blog.leosoto.com
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group
://code.djangoproject.com/changeset/8494
[3] http://code.djangoproject.com/changeset/8526
[4] http://code.djangoproject.com/ticket/10071
--
Leo Soto M.
http://blog.leosoto.com
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"D
On Tue, Jan 20, 2009 at 2:02 AM, Malcolm Tredinnick
<malc...@pointy-stick.com> wrote:
>
> On Tue, 2009-01-20 at 01:54 -0300, Leo Soto M. wrote:
> [...]
>> So I've uploaded a small patch on #10071[4] which does the
>> normalization to int instead of unicode. I test
>).
I wonder if it is also failing on the cx_Oracle backend, as I don't
see any new relevant code which protect against those cases. (Ref:
<http://code.djangoproject.com/ticket/4140>)
Regards,
--
Leo Soto M.
http://blog.leosoto.com
--~--~-~--~~~---~--~~
You
58 matches
Mail list logo
