Google Summer of Code 2009

[Petar Marić]

Will Django be participating in the Google SoC event this year?

Regards,
-- 
Petar Marić
*e-mail: petar.ma...@gmail.com
*mobile: +381 (64) 6122467

*icq: 224720322
*jabber: petar.ma...@gmail.com
*web: http://www.petarmaric.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
-~--~~~~--~~--~--~---

Declarative fixtures for django

[Ben Ford]

Hi All,

I'd like to introduce a little project I've been working on with Kumar
McMillan of farmdev.com. He's the author of the
fixturelibrary which allows a
declarative approach to writing database fixtures.
I've written django support for it so that you can use it to test django
models. The stuff outlined below is in my bitbicket
mirrorbut should be
folded into fixture (the easy_installable version) soon.


Motivation:
-
We've got a pretty big django app, and we've found django's fixtures to be a
little high in maintenance cost... Consider an app that is central to a lot
of other related apps: In our case we have the concept of a business
Network, that has members, a blog, forums documents etc etc and a Profile
which has contacts, an account and a relationship to auth.User.
To do meaningful testing almost all of the fixtures will have to include
some content from the app that contains the Network model and the app that
contains the Profile model. Now if one of the models in either of these apps
changes in structure, then all of the tests that have dumped data from that
model, which will be most of them, will be broken and you'll have to go
through all fixtures and make the required changes.


Fixture
---
Given that the structure of our app changes reasonably regularly and that
repetition can lead to rocking back and forth with unfocussed eyes, I
started to look for "Another Way".
I found fixture in which you declaratively write
DataSetsand
then load them into the database. These DataSets can relate to each
other using standard python syntax so each app can define example fixtures
and other fixtures can import those and declare relations (you can also
subclass rows within the DataSet from each other too). So now when the
schema changes you'll only need to change it on one place and all your tests
should work again.


Example
-

Given the following models:

class Author(models.Model):
first_name = models.CharField(max_length=100)
last_name = models.CharField(max_length=100)

def __unicode__(self):
return u"%s %s" % (self.first_name, self.last_name)

class Book(models.Model):
title = models.CharField(max_length=10)
author = models.ForeignKey(Author, related_name='books')

def __unicode__(self):
return u"%s, %s" % (self.title, self.author)

class Reviewer(models.Model):
name = models.CharField(max_length=100)
reviewed = models.ManyToManyField(Book, related_name='reviewers')

def __unicode__(self):
return u"%s" % (self.name)


A fixture would look like:

from fixture import DataSet
class app__Author(DataSet):
class frank_herbert:
first_name = "Frank"
last_name = "Herbert"
class guido:
first_name = "Guido"
last_name = "Van rossum"

class app__Book(DataSet):
class dune:
title = "Dune"
author = app__Author.frank_herbert

class python:
title = 'Python'
author = app__Author.guido

class app__Reviewer(DataSet):
class ben:
name = 'ben'
reviewed = [app__Book.dune, app__Book.python]


A doctest would look something like this:

>>> from fixture import DjangoFixture
>>> from django.db.models.loading import get_model, get_app
>>> from fixture.test.test_loadable.test_django.util import assert_empty
>>> app = get_app('app')
>>> assert_empty(app) # This just checks that model.objects.count() == 0 for 
>>> all models in app
>>> Book = get_model('app', 'Book')
>>> django_fixture = DjangoFixture()
>>> data = django_fixture.data(app__Book)
>>> data.setup()

All the books are here:

>>> Book.objects.all()
[, 

 And fixture has pulled in all the Authors too, even though only the Book
fixture was explicitly loaded:

>>> Author = get_model('app', 'Author')
>>> Author.objects.all()
[, ]

But not the Reviewers:

>>> get_model('app', 'Reviewer').objects.count()
0

 If we load the app__Reviewers DataSet, all of the others will be pulled in:

>>> data.teardown() # Get rid of the old data
>>> assert_empty(app)
>>> data = django_fixture.data(app__Reviewer)
>>> data.setup()
>>> get_model('app', 'Reviewer').objects.count()
1
>>> Book.objects.count()
2
>>> Author.objects.count()
2
>>> data.teardown()

 I'd like to extend the work I've done to allow serialization of
existing QuerySets to DataSet objects, and better integration with
django's test framework.

So I have a few questions on where to go next...


   1. What's the best way to integrate with django's test framework
   (Transactions, the test client etc). Subclass django's TestCase or something
   else?
   2. I've written some validation code, I'd appreciate it if someone could
   have a look through this
moduleparticularly
the field_is_required func

Re: models: blank, null and oracle

[Evgeniy Ivanov]

On Mar 5, 11:08 pm, Ian Kelly  wrote:
> On Thu, Mar 5, 2009 at 11:57 AM, Evgeniy Ivanov  
> wrote:
>
> > On Mar 5, 6:57 pm, Ian Kelly  wrote:
> >> On Thu, Mar 5, 2009 at 8:37 AM, Evgeniy Ivanov  
> >> wrote:
>
> >> > Hi!
>
> >> > I have such code:
> >> > "name = models.CharField(max_length=32)".
> >> > Thus "blank=False and null=False" should be applied. But in DB this
> >> > attr is nullable, and since oracle stores empty strings as null
> >> > attribute created wrongly (' "NAME " NVARCHAR2 (32) , ').
>
> >> > Should I file a bug?
>
> >> This is intentional.  CharFields are forced to have null=True when
> >> using Oracle.  The reason for this is that you're still allowed to
> >> store the empty string in such a field, even when blank=False.
>
> > Sorry, I'm not sure I understand the reason. Why do I need to be able
> > to store empty strings for CharFields, that marked as required? In
> > docs written, that default values for null and blank are False and
> > also "When using the Oracle database backend, the null=True option
> > will be coerced for string-based fields that can blank, and the value
> > NULL will be stored to denote the empty string". But in our case
> > string-based field's can't blank.
>
> Thanks for pointing that out, because that documentation is wrong.
> The Oracle notes
> (http://docs.djangoproject.com/en/dev/ref/databases/#null-and-empty-st...)
> have it correct, where it says it "coerces the null=True option on
> fields that permit the empty string as a value," which is not the same
> thing as fields with blank=True.  The 'blank' option only affects
> admin validation, not what can actually be stored in the field.

I understand the difference :)

> It
> does not prevent you from explicitly assigning an empty string to the
> field.  Since the other backends will allow this without a hiccup, we
> coerce the option in order to also allow it for compatibility.

Now I understood. Thanks for explonation.


> There is actually no way to prevent Django from doing this.  If you
> really want the column to be not null, you can alter the table
> manually.  But be aware that you effectively lose that constraint if
> you ever port the app to a different backend.
>

I only dislike the thing, that I can do:
"insert into auth_user (id, LAST_LOGIN, DATE_JOINED)
   values ('222', '04-MAR-09 08.58.28.748832 AM', '04-MAR-09
08.58.28.748832 AM');"
for auth.User for example. It's not pretty to have such holes on the
database level.

--~--~-~--~~~---~--~~
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: 'week_day' starting with sunday as first day of a week need to be fixed

[Bob Thomas]

Would it be possible to use cron's weekday numbering? Would that make
anyone happy?

0-7, with both 0 and 7 representing Sunday. That would at least avoid
the %7 part of the workaround (from the user's perspective, anyway).

The "Monday as first day" camp could use 1-7 for their week numbering,
and the "Sunday as first day" could use a 0-indexed week (0-6).
Sheesh, this is starting to sound like a religious war.

I think Karen made the right call here, but if there's a solution that
could make more people happy, it's worth being considered. After all,
once 1.1 goes out, we're stuck with it.

-bob

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

TransactionMiddleware and cursor.execute

[Jeremy Dunck]

The Django docs for TransactionMiddleware state:
"When a request starts, Django starts a transaction. If the response
is produced without problems, Django commits any pending
transactions."

This is apparently not actually true.

I have some code using cursor.execute while doing no operations using
the ORM through a full request cycle-- but it does run under
TransactionMiddleware.  It turns out that if transaction.set_dirty
never gets called, then the request completes without a commit going
to the DB; the DB rightfully interprets this as a rollback.

This caused silent data loss for about a year for me; it wasn't
obvious for some time because my .execute call often coincides with
other ORM use, meaning that a large portion of the data I meant to
save actually did get saved.

I would like basically any data going to the DB to trigger set_dirty.
I *think* this just means cursor.execute with insert/update/delete,
but I haven't reviewed closely yet.

Is there any objection to this change?  I can work up a patch, but
this is obviously a touchy area.

--~--~-~--~~~---~--~~
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: TransactionMiddleware and cursor.execute

[Karen Tracey]

On Fri, Mar 6, 2009 at 10:28 AM, Jeremy Dunck  wrote:

>
> The Django docs for TransactionMiddleware state:
> "When a request starts, Django starts a transaction. If the response
> is produced without problems, Django commits any pending
> transactions."
>
> This is apparently not actually true.
>
> I have some code using cursor.execute while doing no operations using
> the ORM through a full request cycle-- but it does run under
> TransactionMiddleware.  It turns out that if transaction.set_dirty
> never gets called, then the request completes without a commit going
> to the DB; the DB rightfully interprets this as a rollback.
>
> This caused silent data loss for about a year for me; it wasn't
> obvious for some time because my .execute call often coincides with
> other ORM use, meaning that a large portion of the data I meant to
> save actually did get saved.
>
> I would like basically any data going to the DB to trigger set_dirty.
> I *think* this just means cursor.execute with insert/update/delete,
> but I haven't reviewed closely yet.
>
> Is there any objection to this change?  I can work up a patch, but
> this is obviously a touchy area.
>

Sounds like:

http://code.djangoproject.com/ticket/9964

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: TransactionMiddleware and cursor.execute

[Jeremy Dunck]

On Fri, Mar 6, 2009 at 9:34 AM, Karen Tracey  wrote:
> On Fri, Mar 6, 2009 at 10:28 AM, Jeremy Dunck  wrote:
>>
>> The Django docs for TransactionMiddleware state:
>> "When a request starts, Django starts a transaction. If the response
>> is produced without problems, Django commits any pending
>> transactions."
>>
>> This is apparently not actually true.
...
> Sounds like:
>
> http://code.djangoproject.com/ticket/9964

Right you are, thanks for the pointer.

--~--~-~--~~~---~--~~
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: Google Summer of Code 2009

[Jacob Kaplan-Moss]

On Fri, Mar 6, 2009 at 4:07 AM, Petar Marić  wrote:
> Will Django be participating in the Google SoC event this year?

We'll be applying, yes.

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: 'week_day' starting with sunday as first day of a week need to be fixed

[Ivan Sagalaev]

Russell Keith-Magee wrote:
> Semmel and yourself both hang your arguments on the claim that Monday
> as the start of the week is the "most supported" option, or the "most
> common" option. I simply don't see any evidence that this is the case.

I was always under an impression that Sunday is considered first day of 
week only in US. Now Wikipedia (though not the English version) says 
it's also the case for Canada and Israel. But it's still a minority. 
What about Australia, Russell?

--~--~-~--~~~---~--~~
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: 'week_day' starting with sunday as first day of a week need to be fixed

[dc]

Just my two cents. There is at least one other part of the framework
which considers Sunday as the first day:
django.utils.dateformat.DateFormat (and hence some template tags).
Personally i find it annoying but at least this behaviour is
consistent over the framework and that's good.
--~--~-~--~~~---~--~~
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: 'week_day' starting with sunday as first day of a week need to be fixed

[Russell Keith-Magee]

On 07/03/2009, at 2:17 AM, Ivan Sagalaev wrote:
>
> Russell Keith-Magee wrote:
>> Semmel and yourself both hang your arguments on the claim that Monday
>> as the start of the week is the "most supported" option, or the "most
>> common" option. I simply don't see any evidence that this is the  
>> case.
>
> I was always under an impression that Sunday is considered first day  
> of
> week only in US. Now Wikipedia (though not the English version) says
> it's also the case for Canada and Israel. But it's still a minority.
> What about Australia, Russell?

Like all interesting questions, the answer is "it depends" :-)

Printed wall calendars almost universally put Sunday as the first box  
in the week. However, a quick straw poll of the people in my office  
gave opinions 50/50 each way, but everyone agreed that either was just  
as valid and common.

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