Re: Problem with ``Model.objects.create``

On Jan 4, 8:46 pm, Waylan Limberg wrote: > That being said, it does strike me as being a little odd that there is > no way to validate your data when using create() or get_or_create(). > In fact, the docs [1] describe both those methods as shortcuts. But if > you're writing an

Re: Problem with ``Model.objects.create``

On Jan 4, 4:43 pm, Jacob Kaplan-Moss wrote: > On Tue, Jan 4, 2011 at 3:37 PM, Yo-Yo Ma wrote: > > What's with all the hostility here? I've heard about this from others. > > Let's just stop this, right now. There's no hostility in Marty's tone > -- if

Re: Problem with ``Model.objects.create``

On Tue, Jan 4, 2011 at 3:37 PM, Yo-Yo Ma wrote: > What's with all the hostility here? I've heard about this from others. Let's just stop this, right now. There's no hostility in Marty's tone -- if you're reading that, then take the night off and come back to django-dev

Re: Problem with ``Model.objects.create``

Waylan: > Therefore, don't use Person.objects.create() Marty: > Developer mistakes can ruin your data. Full stop. > Unfortunately, this is one of the many issues where "X doesn't work > the way I think it should" gets confused with "X doesn't work the way > it should" or even "X doesn't

Re: Problem with ``Model.objects.create``

On Tue, Jan 4, 2011 at 3:10 PM, Yo-Yo Ma wrote: > Simple question (A or B): Would you rather A) have a > SomeDjangoException come up where you don't expect it and a visitor > see a 500 page, or B) have your data ruined by a developer mistake? Developer mistakes can ruin

Re: Problem with ``Model.objects.create``

>> ...*before* writing to the db. Therefore, don't use >> Person.objects.create() >> ...it does strike me as being a little odd that there is no way to validate >> your data... Let me get this straight: I just shouldn't "use Person.objects.create()", if I ever want to to take advantage

Re: Problem with ``Model.objects.create``

On Tue, Jan 4, 2011 at 10:54 AM, Yo-Yo Ma wrote: [snip] > The difference in Django is that instantiation doesn't represent > "creation". Saving to the database does, and since the ORM is an > abstraction of the database, you don't care that the DB is ok with an > empty

Re: Problem with ``Model.objects.create``

> duplicate key, etc." [1] Since the creation of a model instance > doesn't affect the database, it should definitely not raise an This isn't correct. Model instantiation doesn't affect the database. Model creation (ie, the use of ``Model.create()`` does. I'm not arguing that instantiation should

Re: Problem with ``Model.objects.create``

Just to clarify, an IntegrityError is raised if "the relational integrity of the database is affected, e.g. a foreign key check fails, duplicate key, etc." [1] Since the creation of a model instance doesn't affect the database, it should definitely not raise an IntegrityError. Additionally,

Re: Problem with ``Model.objects.create``

Oh, sorry for the confusion, and thanks for the explaination. I thought that Django raised an IntegrityError in this case, and when it didn't happen I figured it was a bug. I will make a recommendation (observation). To provide a blank value a a model and have it validate with full_clean, you

Re: Problem with ``Model.objects.create``

On Mon, Jan 3, 2011 at 7:46 AM, Yo-Yo Ma wrote: > I apologize ahead of time, if this bug is rather a user error. > > If you have a model: > > class Foo(Model): >    spam= CharField(max_length=30) >    xyz= CharField(max_length=30) > >    def __unicode__(self): >        

Re: Problem with ``Model.objects.create``

This is a user error, validation checks are performed on model.clean() . This mailing list is for development purpose, please use django-usersmailing list or #django irc . --

Problem with ``Model.objects.create``

I apologize ahead of time, if this bug is rather a user error. If you have a model: class Foo(Model): spam= CharField(max_length=30) xyz= CharField(max_length=30) def __unicode__(self): return self.xyz and you use it in the shell like this: >>>