On Tue, Jul 8, 2008 at 8:49 PM, Malcolm Tredinnick
<[EMAIL PROTECTED]> wrote:
> *Deprecation*, dagnabbit! Depreciation is a different word. :-)
Ye grammar gods! I'm usually more on top of things than that. Shame
on me! ^_^
[...]
> Anyway, you've got a few weeks. Probably worth whacking
On Tue, 2008-07-08 at 19:26 -0500, Tom Tobin wrote:
[...]
> I don't want to change the public APIs. If "from django import
> templates" works now, it should work after I'm done. The chief BICs
> would be for importing non-public pieces, and even in those cases I
> think a period with a
Looks like this backend is going quite well. For what it's worth, I
solved the other end of the datetime/date/time problem by patching
django.db.models.query.QuerySet.iterator. I expect there's a better
solution than this but I thought I'd post this because it at least
works.
def
On Tue, Jul 8, 2008 at 6:08 PM, Malcolm Tredinnick
<[EMAIL PROTECTED]> wrote:
>
> On Tue, 2008-07-08 at 09:55 -0500, Tom Tobin wrote:
> [...]
>> I'm curious as to
>> whether others think we can still manage this cleanly post-1.0. If we
>> can, great! — I'll just wait until then. If not, is
On Tue, 2008-07-08 at 09:55 -0500, Tom Tobin wrote:
[...]
> I'm curious as to
> whether others think we can still manage this cleanly post-1.0. If we
> can, great! — I'll just wait until then. If not, is there any chance
> we can squeeze this in somewhere?
It depends on what will change.
On 8 Jul 2008, at 03:17, Rajeev J Sebastian wrote:
>
> The latest PG has its own text indexing/search system ... is this what
> you are referring to by "tsearch2" ?
>
Yes, exactly.
http://www.sai.msu.su/~megera/wiki/Tsearch2_83_changes
There do appear to be naming differences between the 8.2
> Yes, the tests run on Windows now as well. Only problem is two tests with
> file paths in their output, the forward slashes are backslashes on Windows
> so the output doesn't match what the tests are looking for:
>
> http://dpaste.com/61364/
>
> Not sure if/how you ordinarily get around that
On Tue, Jul 8, 2008 at 10:53 AM, Russell Keith-Magee <[EMAIL PROTECTED]>
wrote:
> To the best of my knowledge, there shouldn't be anything else required
> to run the tests, other than python in your system path.
>
> One possible cause is the __init__.py files; there are 3 required in
> total -
Since bringing up the topic a few months ago (and getting support for
the idea) [1], I haven't had time to whip up a patch to move the
contents of various modules' __init__ out into "base" or "main". It
finally clicked (you know, several weeks *after* 1.0 features were
nailed down, ugh) that this
On Mon, Jul 7, 2008 at 11:06 PM, Karen Tracey <[EMAIL PROTECTED]> wrote:
> On Mon, Jul 7, 2008 at 10:00 AM, Russell Keith-Magee
> I get 17 failures running on Ubuntu (gutsy), but maybe I'm missing something
> else needed for the tests to run properly? I just added the
> django-admin-tests.diff
On Mon, Jul 7, 2008 at 10:10 PM, Simon Willison <[EMAIL PROTECTED]> wrote:
>
> On Jul 7, 3:00 pm, "Russell Keith-Magee" <[EMAIL PROTECTED]>
> wrote:
> The bash script appears to be used purely to set the environment
> variables. Is there any reason you can't just directly assign to
> os.environ
Hi Jan,
It sounds like you've made great progress. We have an informal trac and hg
repo set up at trac and hg dot woe-beti.de respectively. you're more than
welcome to add your documentation there! Let me know if you want an hg repo
tp play with too and I'll sort it out for you.
Cheers,
Ben
Works fine for me! Thanks a lot!
On 8 Лип, 16:30, mrts <[EMAIL PROTECTED]> wrote:
> Patch uploaded tohttp://code.djangoproject.com/ticket/7676, please
> test.
>
> On Jul 8, 4:21 pm, sector119 <[EMAIL PROTECTED]> wrote:
>
> > Problems
> > 2. django/core/serializers/__init__.py:
On Mon, Jul 7, 2008 at 10:08 PM, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
>
> One thing to watch for: I'm nearly 100% sure this won't work under the
> buildbot -- it looks like since the settings file is written in the
> same directory as the code you'll get conflicts between simultaneously
>
On Sun, Jul 6, 2008 at 11:39 PM, Joseph Kocherhans
<[EMAIL PROTECTED]> wrote:
>
> Dynamic choices become an argument to the form constructor. The
> argument is a dictionary of fieldname, choices pairs where choices is
> either the choices structure we currently use, or a queryset.
I have to say
On Tue, 2008-07-08 at 21:26 +0800, vcc wrote:
> Thanks for Russ Magee, I see.
>
> I just updated this backend, it's look like everything work fine for me. I
> have some projects working with this backend, I'll keep improve it. Please
> check the patch in the attachments.
So the best thing to
On Tue, Jul 8, 2008 at 8:26 AM, vcc <[EMAIL PROTECTED]> wrote:
> I just updated this backend, it's look like everything work fine for me. I
> have some projects working with this backend, I'll keep improve it. Please
> check the patch in the attachments.
As Russ, and the many previous threads
Patch uploaded to http://code.djangoproject.com/ticket/7676 , please
test.
On Jul 8, 4:21 pm, sector119 <[EMAIL PROTECTED]> wrote:
> Problems
> 2. django/core/serializers/__init__.py: _load_serializers() is
> unsafe, patch attached to #FIXME:
>
> Where can I found the patch? Where is
Problems
2. django/core/serializers/__init__.py: _load_serializers() is
unsafe, patch attached to #FIXME:
Where can I found the patch? Where is "#FIXME:" ? ;)
On 8 Лип, 16:07, mrts <[EMAIL PROTECTED]> wrote:
> I reviewed threading in Django and found a few problems, one of which
> is
DONE!
http://code.djangoproject.com/ticket/7676
--~--~-~--~~~---~--~~
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
I reviewed threading in Django and found a few problems, one of which
is serialization.
See
http://code.djangoproject.com/wiki/DjangoSpecifications/Core/Threading#Problems
.
Fix was contributed to the most eminent one in #6950, but I never got
to fixing serialization.
The fix is easy though,
On Tue, 2008-07-08 at 05:49 -0700, sector119 wrote:
> HI All!
>
> I have to deserialize, serialize objects in multiple threads with
> django serializers.
>
> But when I run Deserializer =
> serializers.get_deserializer(SERIALIZATION_FORMAT) in my threads (more
> then one, with _one_ thread all
HI All!
I have to deserialize, serialize objects in multiple threads with
django serializers.
But when I run Deserializer =
serializers.get_deserializer(SERIALIZATION_FORMAT) in my threads (more
then one, with _one_ thread all works great) I get KeyError in
get_serializer function at `return
Hi guys,
I've been heavily swamped with work for college, so I missed this
thead and the few others on multiple databases. Sorry.
I have implemented a proof-of-concept database scaling solution for
Django. It tackles all kind of scaling issues I have seen in Django.
It's purpose is mainly to
Naruto 408
Naruto 408, One Piece 507, Bleach 329 Hot manga Download
The hottest mangas and the latest chapters
Manga news, Most popular mangas, Latest mangas, Latest chapters
http://english1.isoshu.com/?recommid=1023
http://emanga1.isoshu.com/?recommid=1023
On Jul 8, 5:27 am, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> Increasing
> some value from 32 bits to 64 bits is only changing some probabilities;
> it's not actually solving the problem, just moving the goalposts to make
> it harder to score an own goal. The rest of the conversation should
On Tue, Jul 8, 2008 at 5:10 AM, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
>
> Hi,
> i just updated to the lastest newforms-admin django, and my fixtures
> won't load anymore.
...
> to me this looks like get_or_create is broken in some way.
First off, unless you've actually confirmed that this
Jacob Kaplan-Moss wrote:
> Hi folks --
>
> This is your friendly reminder the three "must-have" features on the
> roadmap are due on two weeks -- Django 1.0 alpha is due for release on
> July 20th.
>
> We've got two sprints between then and now (see
> http://code.djangoproject.com/wiki/Sprints)
On Tue, 2008-07-08 at 19:27 +1000, Malcolm Tredinnick wrote:
[...]
> It's almost like we need some kind of ticket tracking system so that
> these things don't get lost and people won't start threads saying "look
> at mine! look at mine!" Oh, wait ... we do have one of those. :-(
Sorry. That was
El mar, 08-07-2008 a las 19:34 +1000, Malcolm Tredinnick escribió:
> I'll also note that that ticket has sort of weaved it's way up to "ready
> for checkin" without too much participation from core developers and
> it's a bit of a change.
Dunno who the anonymous user was, not me ;) I didn't move
On Tue, 2008-07-08 at 01:24 -0700, [EMAIL PROTECTED] wrote:
> So our team is very fond of Ticket 3148 "Add getters and setters to
> model fields" which is in the "ready for checkin" stage. Does that
> mean it will be merged to the trunk soon (and thus become part of v1
> release)?
>
> If not,
On Tue, 2008-07-08 at 10:30 +0400, Ivan Sagalaev wrote:
> Malcolm Tredinnick wrote:
> > The rest of the conversation should
> > proceed on the assumption that the bug about creating unique database
> > entries will be fixed first.
>
> Now I think that the problem is only exists if one uses
>
I have begun work on the suggestion I made, the current diff is here:
http://dpaste.com/61309/, right now the main issue I have is that
currently AdminSite.root() sets self.root_path which I believe is no
longer necessary(although I could be wrong), but I'm not 100% sure
what it is used for(if it
El mar, 08-07-2008 a las 01:24 -0700, [EMAIL PROTECTED] escribió:
> So our team is very fond of Ticket 3148 "Add getters and setters to
> model fields" which is in the "ready for checkin" stage. Does that
> mean it will be merged to the trunk soon (and thus become part of v1
> release)?
Not
So our team is very fond of Ticket 3148 "Add getters and setters to
model fields" which is in the "ready for checkin" stage. Does that
mean it will be merged to the trunk soon (and thus become part of v1
release)?
If not, what is the designation for tickets that will be part of v1?
thanx,
On Mon, Jul 7, 2008 at 8:29 PM, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> Currently, ReverseSingleRelatedObjectDescriptor uses _default_manager,
> which is the problem (line 239 in django/db/models/related/fields.py).
> One clean solution would be to give each model a _pristine_manager
>
Malcolm Tredinnick wrote:
> The rest of the conversation should
> proceed on the assumption that the bug about creating unique database
> entries will be fixed first.
Now I think that the problem is only exists if one uses
non-transactional DB setup. In this case
due to race conditions one of
Adrian Holovaty wrote:
> This is certainly a bug. The main question is how to fix it.
Oh, it's a big can of worms, actually. I was once pondering on this and
found some tricky cases.
1) Managers are not just restrict querysets by filtering. They can be
used for example to produce custom
38 matches
Mail list logo
