django powered

[mobil]

http://youfindr.com/buzz
--~--~-~--~~~---~--~~
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: Sanity check #8306 (cleaning up formfield_for_dbfield), please

[Jacob Kaplan-Moss]

On Thu, Jan 15, 2009 at 6:43 PM, Brian Rosner  wrote:
> I think this definitely the right direction. An outstanding admin
> ticket that this is touching very heavily on is #3987. You've done a
> really good job making the right abstractions. I went a step further
> and figured this should be included as it does change the method
> signature [2].

Ah, good catch.

Note to self: when in doubt, pass around the request in the admin.
It's almost always a good idea.

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

Re: Unicode filenames

[Marty Alchin]

On Thu, Jan 15, 2009 at 10:33 AM, Marty Alchin  wrote:
> While working again with files for model validation, I realized (and
> confirmed with Russ, Honza and Alex in IRC) that the tests put in as a
> fix for #6009[1] don't actually prove all the behavior that ticket
> refers to. They prove that Unicode filenames come through fine from
> uploads, but that test doesn't actually save the file at all. The
> changes I'm working on for validation cause it to save the file now,
> and the second part of that ticket (dropping too many characters from
> the filename) comes back to bite us.

Correction: it was actually an error in the test that was causing the
failure; the problem just wasn't evident until the changes I put
through. I've put in ticket #10041 to address the problem with the
test.

> I'm not sure if get_valid_filename() needs to be as aggressive as it
> currently is, because a bit of light reading suggests that we should
> be able to work with Unicode filenames, now that Django passes around
> Unicode strings properly throughout. Alas, I'm not an expert in
> Unicode or file systems, so I don't know if I'm overlooking some
> obvious problem with opening the range up to include Unicode
> characters.

This is still a problem, though it's not the cause of any test
failures. The second part of #6009 is still a potential issue, and I'm
still not sure how best to address it. I'm not going to reopen that
ticket, though, nor will I open a new one until I know a bit more
about how to continue.

-Gul

--~--~-~--~~~---~--~~
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: Sanity check #8306 (cleaning up formfield_for_dbfield), please

[Brian Rosner]

On Thu, Jan 15, 2009 at 2:56 PM, Jacob Kaplan-Moss  wrote:
> I'm pretty happy with the approach, but honestly I don't use the admin
> all that hard so I'm not 100% confidant that the design is perfect. So
> I'd love a quick review of the latest patch on #8306 (also available
> on github: 
> http://github.com/jacobian/django/commits/trac/8306-admin-field-overrides).

I think this definitely the right direction. An outstanding admin
ticket that this is touching very heavily on is #3987. You've done a
really good job making the right abstractions. I went a step further
and figured this should be included as it does change the method
signature [2].

[1]: http://code.djangoproject.com/ticket/3987
[2]: 
http://github.com/brosner/django/commit/d6c0a47be4a2ea7743c9e90a4accd43993b4f5bd

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

Re: Problem with ORM

[Jacob Kaplan-Moss]

> Because I deleted that object. Delete method should be non-reversible
> (except in transactions) like "del" statement in Python. Or anybody
> knows any reason, why it should be reversible?

You didn't delete the object. That'd be spelled ``del instance``. You
called a method called ``delete`` on an instance of a ``Model``
object. This is documented as deleting the row in the database that
the object represents. You then called a method named ``save`` on a
``Model`` instance. This is documented as performing an insert if the
row in question does not exist.

If it doesn't behave the way you want it to, I'm sorry. But this is
"correct" behavior: it matches the documentation, and both of them
match the design.

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

Re: Problem with ORM

[Sebastian Bauer]

I think ORM supposed to have save insert and update:

save(force_insert=False,force_update=False)
update() == save(force_update=True)
insert() == save(force_insert=True)

in that situation we could have clean code and we know that update is 
realy update on DB

i now we can have save(force_update=True) but update() looks better and 
we have insert() already

IMHO save() is only wrapper for save_base()

W dniu 16.01.2009 00:15, Jan Bednařík pisze:
> On Thu, Jan 15, 2009 at 11:11 PM, Collin Grady  wrote:
>
>> On Thu, Jan 15, 2009 at 2:09 PM, Jan Bednařík  wrote:
>>  
>>> That should not happen.
>>>
>>> instance.delete()
>>> instance.save()
>>>
>>> should raise ObjectDoesNotExist exception. Any other behavior is bug.
>>>
>> Why? You have a perfectly valid object instance, and you're then saving it.
>>  
>
> Because I deleted that object. Delete method should be non-reversible
> (except in transactions) like "del" statement in Python. Or anybody
> knows any reason, why it should be reversible?
>
> If I try to call save() or any other method on deleted object, than
> it's just and only my mistake and I should get exceptions. But quiet
> undelete effect of save() method can cause lot of "hard to find" bugs
> in final app. Especially if probably nobody is expecting something
> like that.
>
> Jan
>
> >
>
>

--~--~-~--~~~---~--~~
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: Problem with ORM

[Jan Bednařík]

On Thu, Jan 15, 2009 at 11:11 PM, Collin Grady  wrote:
> On Thu, Jan 15, 2009 at 2:09 PM, Jan Bednařík  wrote:
>> That should not happen.
>>
>> instance.delete()
>> instance.save()
>>
>> should raise ObjectDoesNotExist exception. Any other behavior is bug.
>
> Why? You have a perfectly valid object instance, and you're then saving it.

Because I deleted that object. Delete method should be non-reversible
(except in transactions) like "del" statement in Python. Or anybody
knows any reason, why it should be reversible?

If I try to call save() or any other method on deleted object, than
it's just and only my mistake and I should get exceptions. But quiet
undelete effect of save() method can cause lot of "hard to find" bugs
in final app. Especially if probably nobody is expecting something
like that.

Jan

--~--~-~--~~~---~--~~
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: Sanity check #8306 (cleaning up formfield_for_dbfield), please

[Alex Gaynor]

On Thu, Jan 15, 2009 at 4:56 PM, Jacob Kaplan-Moss wrote:

>
> Hi folks --
>
> Building on some work James did, I've cleaned up formfield_for_dbfield
> to make field overrides easier in the admin.
>
> I'm pretty happy with the approach, but honestly I don't use the admin
> all that hard so I'm not 100% confidant that the design is perfect. So
> I'd love a quick review of the latest patch on #8306 (also available
> on github:
> http://github.com/jacobian/django/commits/trac/8306-admin-field-overrides
> ).
>
> The patch is pretty small so hopefully it makes sense, but questions
> of course welcome.
>
> Jacob
>
> >
>
It looks good by me and gives me an easy entry point to use for #9976[1].

Alex


[1]: http://code.djangoproject.com/ticket/9976
-- 
"I disapprove of what you say, but I will defend to the death your right to
say it." --Voltaire
"The people's good is the highest law."--Cicero

--~--~-~--~~~---~--~~
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: Problem with ORM

[Collin Grady]

On Thu, Jan 15, 2009 at 2:09 PM, Jan Bednařík  wrote:
> That should not happen.
>
> instance.delete()
> instance.save()
>
> should raise ObjectDoesNotExist exception. Any other behavior is bug.

Why? You have a perfectly valid object instance, and you're then saving it.

Just like if you had instantiated it.

If you want it to fail if the object is gone, use force_update=True as
you were told before.

This is not an ORM bug, no matter how much you would like it to act otherwise.

-- 
Collin Grady

--~--~-~--~~~---~--~~
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: Problem with ORM

[Jan Bednařík]

2009/1/15 Ian Kelly :
> On Thu, Jan 15, 2009 at 1:58 AM, Jan Bednařík  wrote:
>>
>> On Wed, Jan 14, 2009 at 6:51 PM, Sebastian Bauer  wrote:
>>>
>>> Hi
>>>
>>> I think it's a bug, but maybe im wrong:
>>>
>>>
>>> print Categories.objects.count()
>>>  >>0
>>> new_obj = Categories.objects.create(name="test")
>>> instance_1  = Categories.objects.get(pk=new_obj.pk)
>>> instance_2 = Categories.objects.get(pk=new_obj.pk)
>>>
>>> instance_1.delete()
>>> print Kategorie.objects.count()
>>>  >>0
>>> instance_2.save()
>>> print Kategorie.objects.count()
>>>  >>1
>>>
>>> how orm can save second instance of the same row when its deleted?
>>>
>>> i have 2 options to solve this problem:
>>>
>>> 1. create method of Model instance to check if row exists and let users
>>> to handle it by own
>>> or
>>> 2. throw exception ex. models.DoesNotExist
>>>
>>> what you think about this problem?
>>
>> Hi,
>>
>> this is happening, because Django ORM is not working as what you
>> expect from ORM.
>>
>> In real ORM, this:
>>
>> instance_1 = Categories.objects.get(pk=new_obj.pk)
>> instance_2 = Categories.objects.get(pk=new_obj.pk)
>>
>> will make only one instance with two pointers on it.
>
> No, it's just the behavior of the save method.  You can perform the
> operations above with a single instance and still get the same result
> - the row is deleted and then reinserted.

That should not happen.

instance.delete()
instance.save()

should raise ObjectDoesNotExist exception. Any other behavior is bug.

Jan

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

Sanity check #8306 (cleaning up formfield_for_dbfield), please

[Jacob Kaplan-Moss]

Hi folks --

Building on some work James did, I've cleaned up formfield_for_dbfield
to make field overrides easier in the admin.

I'm pretty happy with the approach, but honestly I don't use the admin
all that hard so I'm not 100% confidant that the design is perfect. So
I'd love a quick review of the latest patch on #8306 (also available
on github: 
http://github.com/jacobian/django/commits/trac/8306-admin-field-overrides).

The patch is pretty small so hopefully it makes sense, but questions
of course welcome.

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

Re: Django setting

[Jacob Kaplan-Moss]

Hi Kevin --

Just like your first question, this one also belongs on django-users.
Please direct your questions over there.

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

Re: deploying django project

[Jacob Kaplan-Moss]

On Thu, Jan 15, 2009 at 2:12 PM, Harryanto Ie  wrote:
> i've looked the django documentation and there are
> solution for deploying django project into web server, but
> when i took those solution and implement to my web server
> (in this case, i use apache), there are several settings
> inside httpd.conf for django that made me confuse...
> can you help me, please?
> thx

As James said, this question and ones like it belong on the
django-users mailing list.

On that list you'll find hundreds of people willing to discuss using
Django in all sorts of deployment scenarios. *This* list, however, is
for discussing the development of Django itself.

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

Re: deploying django project

[Rodrigo Guzman]

One way or another this is a question better suited for the
django-users mailing list:
http://groups.google.com/group/django-users

The developers list is for issues relating to the development of the
internals of django.

On Thu, Jan 15, 2009 at 2:12 PM, Harryanto Ie  wrote:
> i've looked the django documentation and there are
> solution for deploying django project into web server, but
> when i took those solution and implement to my web server
> (in this case, i use apache), there are several settings
> inside httpd.conf for django that made me confuse...
> can you help me, please?
> thx
>
> On Thu, 15 Jan 2009 11:04:49 -0600
>  "James Bennett"  wrote:
>>
>> This question most properly belongs on the django-users
>>list.
>>
>> Also, you may want to consider spending some time with
>>the Django
>> documentation (in particular, searching the docs index
>>for the word
>> "deploy").
>>
>>
>> --
>> "Bureaucrat Conrad, you are technically correct -- the
>>best kind of correct."
>>
>> >
>
> 
> "Flexi - Gratis bicara sepanjang waktu se-Jawa Barat, Banten dan DKI Jakarta."
>
> "Speedy - Gratis internetan unlimited dari pkl. 20.00 s/d 08.00 
> se-Jabodetabek, Banten, Karawang dan Purwakarta."
> 
> "Nikmati akses TelkomNet Instan Week End Net hanya Rp 1.000/jam. Berlaku 
> untuk Sabtu-Minggu, khusus Jawa Tengah dan DIY s/d
>
> 31 Desember 2008".
> 
> "Kini telah hadir Protector, layanan keamanan online yang dapat digunakan 
> langsung saat menjelajahi internet kapan saja dan
>
> di mana saja. Dapatkan secara GRATIS layanan Protector hingga 31 Desember 
> 2008. Klik ke: http://protector.telkomspeedy.com;.
>
> 
>
> Ikuti Speedy Blogging Competition 2008, ajang kompetisi Blog yang terbuka 
> bagi semua Blogger dengan tema: Seperti Apa Konten Hebat Menurutmu? Dapatkan 
> hadiah utama 1 Buah Notebook Mininote. Informasi lebih lanjut kunjungi 
> http://lomba.blog.telkomspeedy.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 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Django setting

[Kevin89]

how's to make the port number dissapear from the localhost or
webserver?
when i run the server, (localhost using python), it's showing the
statement that django project running at 127.0.0.1:8000
where is the file that must be changed to dissapear the port number?
thx
--~--~-~--~~~---~--~~
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: deploying django project

[Harryanto Ie]

i've looked the django documentation and there are 
solution for deploying django project into web server, but 
when i took those solution and implement to my web server 
(in this case, i use apache), there are several settings 
inside httpd.conf for django that made me confuse...
can you help me, please?
thx
  
On Thu, 15 Jan 2009 11:04:49 -0600
  "James Bennett"  wrote:
> 
> This question most properly belongs on the django-users 
>list.
> 
> Also, you may want to consider spending some time with 
>the Django
> documentation (in particular, searching the docs index 
>for the word
> "deploy").
> 
> 
> -- 
> "Bureaucrat Conrad, you are technically correct -- the 
>best kind of correct."
> 
> > 


"Flexi - Gratis bicara sepanjang waktu se-Jawa Barat, Banten dan DKI Jakarta."

"Speedy - Gratis internetan unlimited dari pkl. 20.00 s/d 08.00 se-Jabodetabek, 
Banten, Karawang dan Purwakarta."

“Nikmati akses TelkomNet Instan Week End Net hanya Rp 1.000/jam. Berlaku untuk 
Sabtu-Minggu, khusus Jawa Tengah dan DIY s/d 

31 Desember 2008”.

"Kini telah hadir Protector, layanan keamanan online yang dapat digunakan 
langsung saat menjelajahi internet kapan saja dan 

di mana saja. Dapatkan secara GRATIS layanan Protector hingga 31 Desember 2008. 
Klik ke: http://protector.telkomspeedy.com;.



Ikuti Speedy Blogging Competition 2008, ajang kompetisi Blog yang terbuka bagi 
semua Blogger dengan tema: Seperti Apa Konten Hebat Menurutmu? Dapatkan hadiah 
utama 1 Buah Notebook Mininote. Informasi lebih lanjut kunjungi 
http://lomba.blog.telkomspeedy.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 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Rolling back tests -- status and open issues

[Karen Tracey]

On Thu, Jan 15, 2009 at 1:12 PM, Eric Holscher wrote:

> You both are indeed correct. I certainly think that the current patch can
> go in today as presented. The Ellington test suite is passing with a 10x
> speedup. We can get it to 40x speedup if we change out doctests that load
> fixtures into unit tests (which probably makes more sense anyway). From 2
> hours down to 3 minutes is amazing.
>
> Thanks for all the hard work, and I'm really excited to see this going into
> Django. Django development will be much improved with this change.
>

Cool -- I'm glad to hear the Ellington suite has no problems I was unaware
of.

Earlier today I added some doc for the changes, and I've been verifying that
the full Django test suite (including the aggregation changes) with the
latest #8138 patch produces the same results as trunk on sqlite, Oracle,
PostgreSQL, MySQL/InnoDB, and MySQL/MyISAM.  The first three are verified,
the last two are currently running.

Assuming no problems crop up in the two that are still running, I'd like to
check this in tonight -- if there are any objections, or more time is needed
for others to review the current patch, please speak up in the next six
hours or so.

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: Rolling back tests -- status and open issues

[Eric Holscher]

On Thu, Jan 15, 2009 at 12:06 PM, Karen Tracey  wrote:

> On Wed, Jan 14, 2009 at 5:35 PM, Russell Keith-Magee <
> freakboy3...@gmail.com> wrote:
>
>>
>> On Thu, Jan 15, 2009 at 5:40 AM, Eric Holscher 
>> wrote:
>> > I think that if there is a plan to ever include fixtures into doctests,
>> then
>> > we should put transaction management into them. We should also decide on
>> a
>> > syntax (__fixtures__ really isn't too bad). This is mostly a bikeshed,
>> where
>> > if it's going to happen, we just need to decide something that works and
>> go
>> > with it. Otherwise we should go ahead and close #5624, and say that
>> doctests
>> > are only for simple cases where you are generating the objects yourself.
>> > This means that we will internally write out doctests that require
>> fixtures
>> > back into unit tests, but this isn't a huge deal.
>> >
>> > I think we should just decide now, and stick with it. I really don't
>> have a
>> > preference, because I don't think that doctests should be used as
>> > extensively as they are. I know a big reason they were used before is
>> > because they were faster, which now a moot point. If we just say "we
>> will
>> > never have fixtures or transactions on doctests", then we can just be
>> done
>> > with it.
>> >
>> > 1: http://code.djangoproject.com/ticket/5624
>>
>> There is two issues at work here.
>>  1) Is #5625 a good idea?
>>  2) Do we need to implement it right now?
>>
>> Regardless of the answer to (1), (2) is the more pressing concern -
>> given that we're days away from a v1.1 feature freeze, and we're
>> probably behind schedule as it is, now isn't the time to start with
>> unnecessary feature creep. As far as I can tell, #5625 can be safely
>> deferred to v1.2 without losing functionality or being boxed into a
>> corner by #8138. Given that there isn't any urgency brought on by a
>> need to meet v1.1 commitments, I suggest that we should defer this
>> discussion to the next planning cycle.
>>
>
> I agree.  As it is now #8138 doesn't change the behavior of doctests, so
> far as I know.  Trying to do the same thing for them as was done for
> django.test.UnitTest code -- running them in a rolled-back transaction and
> preventing them from calling transaction routines -- led to more weird
> errors in the Django test suite.  Given time I'm sure they can be figured
> out, but I think there's some design work involved in order to come up with
> a way for them to opt-out of the change, as TestCases can do by switching to
> TransactionTestCase.  It seems there is similar work to be done for
> extending them to auto-load fixtures, and it would make sense coordinate
> that work so that all Django "doctest extensions" have a similar feel, use a
> consistent mechanism, etc.  But we don't have time to do that for 1.1, I
> don't think.  But I don't think it's necessary to say at this point we can
> never do it.
>
> I'm hopeful #8138 can go in (today -- to make the major feature freeze
> deadline?) for 1.1 pretty much as it is now.  It provides good speedup for
> Django TestCases.  So far as I know doctests are now unaffected by it -- if
> I'm missing something there in terms of the latest patch on #8138 breaking
> doctests please let me know.
>
> Karen
>
> >
>
You both are indeed correct. I certainly think that the current patch can go
in today as presented. The Ellington test suite is passing with a 10x
speedup. We can get it to 40x speedup if we change out doctests that load
fixtures into unit tests (which probably makes more sense anyway). From 2
hours down to 3 minutes is amazing.

Thanks for all the hard work, and I'm really excited to see this going into
Django. Django development will be much improved with this change.

Cheers,
Eric



-- 
Eric Holscher
Web Developer at The World Company in Lawrence, Ks
http://ericholscher.com
e...@ericholscher.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 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Rolling back tests -- status and open issues

[Karen Tracey]

On Wed, Jan 14, 2009 at 5:35 PM, Russell Keith-Magee  wrote:

>
> On Thu, Jan 15, 2009 at 5:40 AM, Eric Holscher 
> wrote:
> > I think that if there is a plan to ever include fixtures into doctests,
> then
> > we should put transaction management into them. We should also decide on
> a
> > syntax (__fixtures__ really isn't too bad). This is mostly a bikeshed,
> where
> > if it's going to happen, we just need to decide something that works and
> go
> > with it. Otherwise we should go ahead and close #5624, and say that
> doctests
> > are only for simple cases where you are generating the objects yourself.
> > This means that we will internally write out doctests that require
> fixtures
> > back into unit tests, but this isn't a huge deal.
> >
> > I think we should just decide now, and stick with it. I really don't have
> a
> > preference, because I don't think that doctests should be used as
> > extensively as they are. I know a big reason they were used before is
> > because they were faster, which now a moot point. If we just say "we will
> > never have fixtures or transactions on doctests", then we can just be
> done
> > with it.
> >
> > 1: http://code.djangoproject.com/ticket/5624
>
> There is two issues at work here.
>  1) Is #5625 a good idea?
>  2) Do we need to implement it right now?
>
> Regardless of the answer to (1), (2) is the more pressing concern -
> given that we're days away from a v1.1 feature freeze, and we're
> probably behind schedule as it is, now isn't the time to start with
> unnecessary feature creep. As far as I can tell, #5625 can be safely
> deferred to v1.2 without losing functionality or being boxed into a
> corner by #8138. Given that there isn't any urgency brought on by a
> need to meet v1.1 commitments, I suggest that we should defer this
> discussion to the next planning cycle.
>

I agree.  As it is now #8138 doesn't change the behavior of doctests, so far
as I know.  Trying to do the same thing for them as was done for
django.test.UnitTest code -- running them in a rolled-back transaction and
preventing them from calling transaction routines -- led to more weird
errors in the Django test suite.  Given time I'm sure they can be figured
out, but I think there's some design work involved in order to come up with
a way for them to opt-out of the change, as TestCases can do by switching to
TransactionTestCase.  It seems there is similar work to be done for
extending them to auto-load fixtures, and it would make sense coordinate
that work so that all Django "doctest extensions" have a similar feel, use a
consistent mechanism, etc.  But we don't have time to do that for 1.1, I
don't think.  But I don't think it's necessary to say at this point we can
never do it.

I'm hopeful #8138 can go in (today -- to make the major feature freeze
deadline?) for 1.1 pretty much as it is now.  It provides good speedup for
Django TestCases.  So far as I know doctests are now unaffected by it -- if
I'm missing something there in terms of the latest patch on #8138 breaking
doctests please let me know.

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: deploying django project

[James Bennett]

This question most properly belongs on the django-users list.

Also, you may want to consider spending some time with the Django
documentation (in particular, searching the docs index for the word
"deploy").


-- 
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."

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

deploying django project

[Kevin89]

i've finished my django project development and i want to deploy it to
web server, but i can't deploy it, what is the step that i must do for
deploying django project? i use apache as the web server. thx

--~--~-~--~~~---~--~~
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: Problem with ORM

[Ian Kelly]

On Thu, Jan 15, 2009 at 1:58 AM, Jan Bednařík  wrote:
>
> On Wed, Jan 14, 2009 at 6:51 PM, Sebastian Bauer  wrote:
>>
>> Hi
>>
>> I think it's a bug, but maybe im wrong:
>>
>>
>> print Categories.objects.count()
>>  >>0
>> new_obj = Categories.objects.create(name="test")
>> instance_1  = Categories.objects.get(pk=new_obj.pk)
>> instance_2 = Categories.objects.get(pk=new_obj.pk)
>>
>> instance_1.delete()
>> print Kategorie.objects.count()
>>  >>0
>> instance_2.save()
>> print Kategorie.objects.count()
>>  >>1
>>
>> how orm can save second instance of the same row when its deleted?
>>
>> i have 2 options to solve this problem:
>>
>> 1. create method of Model instance to check if row exists and let users
>> to handle it by own
>> or
>> 2. throw exception ex. models.DoesNotExist
>>
>> what you think about this problem?
>
> Hi,
>
> this is happening, because Django ORM is not working as what you
> expect from ORM.
>
> In real ORM, this:
>
> instance_1 = Categories.objects.get(pk=new_obj.pk)
> instance_2 = Categories.objects.get(pk=new_obj.pk)
>
> will make only one instance with two pointers on it.

No, it's just the behavior of the save method.  You can perform the
operations above with a single instance and still get the same result
- the row is deleted and then reinserted.

Ian

--~--~-~--~~~---~--~~
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: Aggregates come to Django

[Ariel Mauricio Nunez Gomez]

Russ, thanks a lot for your work on this feature and for letting us track
the development on your git branch.

Regards

Ariel.

--~--~-~--~~~---~--~~
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: Aggregates come to Django

[Nicolas Lara]

Russell,

You forgot to thank yourself for the great mentoring you did for me during
Summer of Code, getting the API to rock and for all the work you put into
making the code better after SoC was finished. =)

I am very glad to see this finally come to trunk!

On Thu, Jan 15, 2009 at 11:55 AM, Russell Keith-Magee <
freakboy3...@gmail.com> wrote:

>
> Hi all,
>
> For those watching trunk, revision 9742 added aggregate support to
> Django. (Yay!)
>
> The short version is that Querysets now have two additional operations
> - annotate() and aggregate(). For details on how to use these new
> operations, see the documentation:
>
> http://docs.djangoproject.com/en/dev/topics/db/aggregation/
>
> As prior warning - there is one known problem which we are still
> tracking down. On Windows, using SQLite and Python 2.5, date and
> decimal values can get corrupted. This doesn't affect other versions
> of Python (2.4 or 2.6) on Windows, or Python 2.5 on Linux/Mac. I hope
> to get these problems cleared up very soon. If you are affected,
> either don't update your SVN checkout, or use a different version of
> Python (multiple Python versions co-exist fairly easily under
> Windows).
>
> I've opened ticket #10031 to track this known problem. If you find any
> other issues with aggregates, please open a ticket (or ask on the
> mailing list/IRC if you're unsure if the problem is usage or bug).
>
> Lastly - some thank-yous. This commit wouldn't have been possible
> without the assistance of many other people.
>
> Nicolas Lara did some excellent work turning a specification into a
> working implementation as part of the 2008 Google Summer of Code.
> Nicolas - take a bow - you did some excellent work here.
>
> Alex Gaynor provided some excellent assistance debugging and fixing a
> number of problems as we neared completion of the project. Thanks
> Alex.
>
> Justin Bronn used his GIS-fu to get aggregates working with
> contrib.gis. Thanks Justin.
>
> Karen Tracey used her massive personal server farm to provide
> cross-platform testing. Thanks Karen.
>
> Ian Kelly helped out testing and fixing aggregates on Oracle. Thanks Ian.
>
> Malcolm Tredinnick did his usual stunning job at reviewing code and
> picking holes in designs. Thanks Malcolm.
>
> Thanks also to the many people that contributed ideas during the
> design phase, and to those who tested the code as it was developing.
> Your efforts may not have ended up in the final design or turned into
> a bug report, but thanks for taking the time to look at an
> experimental feature.
>
> Yours,
> Russ Magee %-)
>
> >
>


-- 
Nicolas Lara
Linux user #380134
http://nicolas-lara.blogspot.com/
Public key id: 0x152e7713 at http://keyserver.noreply.org/

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

Unicode filenames

[Marty Alchin]

While working again with files for model validation, I realized (and
confirmed with Russ, Honza and Alex in IRC) that the tests put in as a
fix for #6009[1] don't actually prove all the behavior that ticket
refers to. They prove that Unicode filenames come through fine from
uploads, but that test doesn't actually save the file at all. The
changes I'm working on for validation cause it to save the file now,
and the second part of that ticket (dropping too many characters from
the filename) comes back to bite us.

I'm not sure if get_valid_filename() needs to be as aggressive as it
currently is, because a bit of light reading suggests that we should
be able to work with Unicode filenames, now that Django passes around
Unicode strings properly throughout. Alas, I'm not an expert in
Unicode or file systems, so I don't know if I'm overlooking some
obvious problem with opening the range up to include Unicode
characters.

I'd like to get this fixed one way or another before putting my file
patch into model validation, because it introduces a mostly unrelated
failure that I'd rather avoid. Does anybody with more experience in
this area have any thoughts on how we can go about it? For reference,
you can spot the failure by applying a simple patch to the test.[2]

-Gul

[1] http://code.djangoproject.com/ticket/6009
[2] http://media.martyalchin.com/6009-test.diff

--~--~-~--~~~---~--~~
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: Problem with ORM

[James Bennett]

On Thu, Jan 15, 2009 at 2:58 AM, Jan Bednařík  wrote:
> this is happening, because Django ORM is not working as what you
> expect from ORM.
>
> In real ORM, this:

No... I don't think you mean "real ORM", I think you mean
"identity-mapping ORM". Those terms are not the same.


-- 
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."

--~--~-~--~~~---~--~~
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: Problem with ORM

[Jan Bednařík]

On Wed, Jan 14, 2009 at 6:51 PM, Sebastian Bauer  wrote:
>
> Hi
>
> I think it's a bug, but maybe im wrong:
>
>
> print Categories.objects.count()
>  >>0
> new_obj = Categories.objects.create(name="test")
> instance_1  = Categories.objects.get(pk=new_obj.pk)
> instance_2 = Categories.objects.get(pk=new_obj.pk)
>
> instance_1.delete()
> print Kategorie.objects.count()
>  >>0
> instance_2.save()
> print Kategorie.objects.count()
>  >>1
>
> how orm can save second instance of the same row when its deleted?
>
> i have 2 options to solve this problem:
>
> 1. create method of Model instance to check if row exists and let users
> to handle it by own
> or
> 2. throw exception ex. models.DoesNotExist
>
> what you think about this problem?

Hi,

this is happening, because Django ORM is not working as what you
expect from ORM.

In real ORM, this:

instance_1 = Categories.objects.get(pk=new_obj.pk)
instance_2 = Categories.objects.get(pk=new_obj.pk)

will make only one instance with two pointers on it.

This features are in progress, see
http://code.djangoproject.com/wiki/DjangoSpecifications/Core/SingleInstance
and we can hope, that they will be finished soon.

Jan

--~--~-~--~~~---~--~~
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: Aggregates come to Django

[Alex Gaynor]

On Thu, Jan 15, 2009 at 6:57 AM, Ivan Sagalaev
wrote:

>
> Russell Keith-Magee wrote:
> > For those watching trunk, revision 9742 added aggregate support to
> > Django. (Yay!)
>
> Thank you all very much! This is big.
>
> >
> Tremendous thanks to Nicholas for writing this thing, and to Russ for
making us all do it the right way, also for waiting 3 years to get his pony.

Alex


-- 
"I disapprove of what you say, but I will defend to the death your right to
say it." --Voltaire
"The people's good is the highest law."--Cicero

--~--~-~--~~~---~--~~
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.contrib.sitemaps Additions and Tweaks

[Russell Keith-Magee]

On Thu, Jan 15, 2009 at 2:51 AM, David Cramer  wrote:
>
> Actually before I get a "wtf" response, I should note that the two
> generators do not quite match. One is rendering a template, the other
> is simply yielding XML. The latter approach is what I prefer, but I
> was rushing to finish the index generator :)

You get a WTF response from me, but not for the reason you mention.

David, you've been around the Django community for a while. You've
spoken at DjangoCon. You subscribe to Django-developers. You've
participated in discussions about the feature list for v1.1.

A casual glance at the wiki page tracking progress on the v1.1 release
would reveal that we're behind schedule (or, at least, there are a lot
of must have features that haven't been committed yet). A casual
glance at the activity on django-developers for the last few days
would reveal discussions on several of these features that are
occupying several of the core developers.

Yet you choose the day before the v1.1 alpha feature deadline to make
a feature proposal.

How about you table this for a while and bring it back when we're in a
position to pay attention to feature proposals, rather than when we're
all busy working on the features we've already agreed are necessary?

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: Aggregates come to Django

[Ivan Sagalaev]

Russell Keith-Magee wrote:
> For those watching trunk, revision 9742 added aggregate support to
> Django. (Yay!)

Thank you all very much! This is big.

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

Aggregates come to Django

[Russell Keith-Magee]

Hi all,

For those watching trunk, revision 9742 added aggregate support to
Django. (Yay!)

The short version is that Querysets now have two additional operations
- annotate() and aggregate(). For details on how to use these new
operations, see the documentation:

http://docs.djangoproject.com/en/dev/topics/db/aggregation/

As prior warning - there is one known problem which we are still
tracking down. On Windows, using SQLite and Python 2.5, date and
decimal values can get corrupted. This doesn't affect other versions
of Python (2.4 or 2.6) on Windows, or Python 2.5 on Linux/Mac. I hope
to get these problems cleared up very soon. If you are affected,
either don't update your SVN checkout, or use a different version of
Python (multiple Python versions co-exist fairly easily under
Windows).

I've opened ticket #10031 to track this known problem. If you find any
other issues with aggregates, please open a ticket (or ask on the
mailing list/IRC if you're unsure if the problem is usage or bug).

Lastly - some thank-yous. This commit wouldn't have been possible
without the assistance of many other people.

Nicolas Lara did some excellent work turning a specification into a
working implementation as part of the 2008 Google Summer of Code.
Nicolas - take a bow - you did some excellent work here.

Alex Gaynor provided some excellent assistance debugging and fixing a
number of problems as we neared completion of the project. Thanks
Alex.

Justin Bronn used his GIS-fu to get aggregates working with
contrib.gis. Thanks Justin.

Karen Tracey used her massive personal server farm to provide
cross-platform testing. Thanks Karen.

Ian Kelly helped out testing and fixing aggregates on Oracle. Thanks Ian.

Malcolm Tredinnick did his usual stunning job at reviewing code and
picking holes in designs. Thanks Malcolm.

Thanks also to the many people that contributed ideas during the
design phase, and to those who tested the code as it was developing.
Your efforts may not have ended up in the final design or turned into
a bug report, but thanks for taking the time to look at an
experimental feature.

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