Re: Problem with history view in admin page

[Russell Keith-Magee]

On Tue, Nov 24, 2009 at 1:07 PM, Mario Briggs  wrote:
>>>
> What is stored in this field is a string-serialized representation of
> the
> primary key value.
> <<
>
> I agree that INTEGER is not the right choice, but then so too is CLOB.
> How long is this string-serialized representation going to be? greater
> than 4000 characters ? Varchar(X)  where X is > 4000 or something is
> then the right choice. This is validated by what Karen says is the
> Oracle fix.

Well, Django doesn't make the decision to use CLOB - that's in the
hands of your backend. In the same circumstances, SQLite and Postgres
use 'text'. MySQL uses 'longtext'. Oracle uses 'NCLOB'

In theory, the contents of the object_id field could be anything -
including a string of arbitrary length (i.e., a TextField). However,
in practice, I would be surprised to see 4000+ characters for
object_id - most primary keys are going to be integers, and the ones
that aren't are likely to be short strings or string-like datatypes.

I can't comment on what would be an appropriate datatype for DB2 in
this context.

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-develop...@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 history view in admin page

[Mario Briggs]

>>
What is stored in this field is a string-serialized representation of
the
primary key value.
<<

I agree that INTEGER is not the right choice, but then so too is CLOB.
How long is this string-serialized representation going to be? greater
than 4000 characters ? Varchar(X)  where X is > 4000 or something is
then the right choice. This is validated by what Karen says is the
Oracle fix.

Note: the original workaround provided to Helgi was to use varchar
(3000) and if willing to be more adventurous then try INTEGER

thanks
Mario

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: Design decision on FileField removing abandoned files?

[Tim]

I'm with you, if not on 100% of what you said, at least 95% of it :)

> That said, if throwing directory deleting out
> is the thing that's required to get the patch in, I won't object ;)

I just foresee that if there is heavy hesitation on even deleting
files, deleting directories might be too liberal a feature for the
kind of position that the framework takes.  I don't doubt that
directory deletion has its use, and that it's safe when used
properly.  I think that the primary committors (of which I am most
certainly not) would not think that it was a critical piece of the
framework.  So that being said, I'm just folding on that one without
any argument

> It never occurred to me that we would not a least want the option to
> delete the file from disk. I would guess that in 95% of projects
> people have exactly one FileField in charge of a particular file.

And that's where this patch has an excellent point.  Like I kicked
things off by saying, letting Django help out and delete a file is
hardly different than me hacking in a blind file deletion and
'pass'ing on the exception.  I don't think that anybody can argue that
there shouldn't at least be the checkbox for "clear this field", even
if the file *isn't* deleted.  But, without  the ability to actually
remove the file, I'm unsure that we can say that the FileField and its
derivatives are doing 100% of the job that I'm sure a lot of us expect
it to do.

For the sake of bringing the real-world use case into the picture,
I've got an admin change form which has a few FileFields for various
uses, such as cover letter documents, email lists, etc.  I discard the
original file name in favor of something streamlined, like
"email_list.csv".  Pretty reasonable.  But even the smartest system
admin sitting next to me can't do anything about the utterly useless
duplicate files that pile up on the remote server, without some SSH
credentials.

So, where the core developers and decision makers might hesitate to
delete a file that I declare useless, this patch would instead pick up
the slack.  The files left behind are 100% useless if I say so.
Consider me using a hosted solution, where I can't be bothered with
logging in each week and clearing abandoned files out of a folder.
The typical "set up a cron job" (or similar) approach doesn't work in
every case.

> This was classified as
> "Small/just bugs" when deciding on features for 1.1 by the way [2].

If that's the case, then that's find it it waits until bugfix phase.
I had thought it to be a feature addition, but I'll adjust my
understanding accordingly!

I hope that a patch which has predated version 1.0 can at last get a
decision made.  I'm of course bias toward it being implemented very
nearly as-is, but a decision is at least a decision.

*peacefully waiting for bugfix phase*

Tim

On Nov 23, 9:41 pm, Jonas Pfeil  wrote:
> > It has a kind of goofy option for deleting
> > empty directories when removing a file leaves said directory empty.
>
> Hey, it's not goofy. It's handy ;) I also took _great_ care when
> writing the code for directory deletion and it's happily deleting
> directories on our production server since a year or so. And it's of
> course off by default. That said, if throwing directory deleting out
> is the thing that's required to get the patch in, I won't object ;)
>
> > The patch is marked as "Accepted", but there's some discussion on the
> > comments about "deleting files" not being within the scope of what the
> > patch should do.  I think the intended suggestion is that the patch
> > should clear the DB field pointing to the file, yet not remove the
> > file itself.
>
> Originally I wrote the patch for 1.0 starting with code that Brian
> gave me. As can be seen from his comment the change was a bit too big
> to get in at the last minute.
>
> It never occurred to me that we would not a least want the option to
> delete the file from disk. I would guess that in 95% of projects
> people have exactly one FileField in charge of a particular file. But
> I can see how deleting files by default is potentially dangerous for a
> framework.
>
> In the current patch just changing the default behavior to not delete
> files creates a lot of work for the probably 95% of people who want to
> delete the file form disk. I personally would find an option in the
> settings file most convenient. Adding an option to the model field
> that let's me say "yep, this field has permission to physically delete
> it's file" would also be OK.
>
> > So once again, in summary, I'd like to petition for something of a
> > conclusive decision about file deletion, this time on the above-noted
> > patch.  The ticket comments mention that it would be too late for
> > introducing a feature like that into the development cycle, but that
> > looks like it was from the 1.1 days.  I don't want something like this
> > to slip beyond the end of December, and then have it ignored until a
> > 1.3-ish release.
>
> +1 to that 

Re: Design decision on FileField removing abandoned files?

[Jonas Pfeil]

> It has a kind of goofy option for deleting
> empty directories when removing a file leaves said directory empty.

Hey, it's not goofy. It's handy ;) I also took _great_ care when
writing the code for directory deletion and it's happily deleting
directories on our production server since a year or so. And it's of
course off by default. That said, if throwing directory deleting out
is the thing that's required to get the patch in, I won't object ;)

> The patch is marked as "Accepted", but there's some discussion on the
> comments about "deleting files" not being within the scope of what the
> patch should do.  I think the intended suggestion is that the patch
> should clear the DB field pointing to the file, yet not remove the
> file itself.

Originally I wrote the patch for 1.0 starting with code that Brian
gave me. As can be seen from his comment the change was a bit too big
to get in at the last minute.

It never occurred to me that we would not a least want the option to
delete the file from disk. I would guess that in 95% of projects
people have exactly one FileField in charge of a particular file. But
I can see how deleting files by default is potentially dangerous for a
framework.

In the current patch just changing the default behavior to not delete
files creates a lot of work for the probably 95% of people who want to
delete the file form disk. I personally would find an option in the
settings file most convenient. Adding an option to the model field
that let's me say "yep, this field has permission to physically delete
it's file" would also be OK.

> So once again, in summary, I'd like to petition for something of a
> conclusive decision about file deletion, this time on the above-noted
> patch.  The ticket comments mention that it would be too late for
> introducing a feature like that into the development cycle, but that
> looks like it was from the 1.1 days.  I don't want something like this
> to slip beyond the end of December, and then have it ignored until a
> 1.3-ish release.

+1 to that ;) Although as Russell pointed out here [1] we are in
feature development phase and as long as this really get's looked at
in the bug fixing phase I won't say anything ;) This was classified as
"Small/just bugs" when deciding on features for 1.1 by the way [2].

Cheers,

Jonas

[1] 
http://groups.google.com/group/django-developers/browse_thread/thread/48a445e2f90ff644
[2] http://code.djangoproject.com/wiki/Version1.1Features

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: Scaffolding

[Jean-Christophe Kermagoret]

Hi,
I'm working a lot on Model Driven Software Development in the SIDE-Labs 
project and your approach definitely has a lot of interests for me. We 
currently chose to work on Alfresco as a framework but we are looking 
after technological alternatives.

Have you been a little further in your thinking?

JC

gareth rushgrove a écrit :
> 2009/11/19 Russell Keith-Magee :
>   
>> On Thu, Nov 19, 2009 at 6:47 PM, Thierry  
>> wrote:
>> 
>>> Ok scaffolding has seen a lot of ups and downs in the dev community.
>>>
>>> Type 2
>>> Intelligent code snippets (generation) such as create_app
>>>
>>> Django needs more of the later.
>>> If i have a model, i would like to be able to generate:
>>> - 2 views (list, edit-detail-remove)
>>> - 2 templates
>>> - a modelform
>>> - the neccesary url config
>>>
>>> So I can start working from there, instead of starting from scratch.
>>> Symfony had this nicely worked out.
>>> Is there any django design convention which stops us from having a
>>> management command for this type of Scaffolding?
>>>   
>> However, if you're enthused about having more scaffolding-style tools,
>> then you can start this as a standalone project - after all, you are
>> able to define your own management commands if you want. If it turns
>> out that your management commands are particularly useful and develop
>> a strong following as an external project, then we can see about
>> merging them into the core.
>>
>> 
>
> I've been using paster for this and it works really well. I've started
> compiling these into a project on GitHub based on a few conventions
> myself and a few others use:
>
> http://github.com/garethr/django-project-templates
>
> At the moment I only have one overall template but am just finishing
> off templates for production configs on different environments
> (apache, mod_wsgi, spawning) and but I'd be happy for others to get
> involved. If nothing else feel free to steal the paster template code.
>
> Reading this makes me think wrapping this in a management command
> would make it easier for Django people to get started.
>
> Ta
>
> G
>
>   
>> 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-develop...@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=.
>>
>>
>>
>> 
>
>
>
>   
--
http://www.side-labs.org / Model.Generate.Deploy

-- 
Jean-Christophe Kermagoret
Directeur associe

BlueXML
40, bd Jean Ingres
44100 Nantes

Tel. : +33.2.40.46.62.78
Mob. : +33.6.08.56.83.80

BlueXML : http://www.bluexml.com
SIDE-Labs : http://www.side-labs.org
KerBlue : http://www.kerblue.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-develop...@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.

Feedback on ticket 7777

[thebitguru]

Hi,

Can I please get some feedback on this ticket?  I am hoping that we
can get this in soon.

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

Thanks,
Farhan

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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=.

Re: Public method for getting model field names in order of definition

[Anssi Kaariainen]

> Thanks for the example, but that's not a ModelForm.
>
> Richard

Another try, view.py:

from django.forms.models import model_to_dict

def view(request):
data = Foo.objects.all()[0]
print data.start
form = Example(data=model_to_dict(data))
return render_to_response('t.html', {'form': form})

Where Example is a ModelForm for model Foo.

Seems like there is no easy way to get access to the initial data of a
field in a template. Example(instance=foo) will only populate the
forms initial dict but not data. Should there be a similar property
for initial in BaseForm as there is for data?

Anssi Kääriäinen

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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=.

Re: Public method for getting model field names in order of definition

[Richard Laager]

On Mon, 2009-11-23 at 04:56 -0800, Anssi Kaariainen wrote:
> Here is a working example.
> data = {'field1': 'Foo', 'field2': 10}
> form = Example(data=data)

Thanks for the example, but that's not a ModelForm.

Richard

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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=.

Re: Design decision on FileField removing abandoned files?

[Tim]

After some more searching of the current 1.2 tickets, #7048 [1] seems
like it does the job.  It has a kind of goofy option for deleting
empty directories when removing a file leaves said directory empty.
If this were merged together with the existing models.FileField class,
it would perfectly fix what I suggest be done.

As the author of the patch says:

> Currently ... blank=True on FileFields currently means "blank
first, then set forever".
> Which is a not the most common use case IMHO ;)

The patch is marked as "Accepted", but there's some discussion on the
comments about "deleting files" not being within the scope of what the
patch should do.  I think the intended suggestion is that the patch
should clear the DB field pointing to the file, yet not remove the
file itself.

Which sort of lands us back at the initial discussion I brought up in
the first post.  Now, for the record, I'm totally against an option
for removing directories.  That most certainly intrudes on the file
system far more than acceptable.  It's far from a required feature for
the Django core, and has a rare use case at best.  But, as for the
basic file clearing and deletion, it doesn't seem to me that it ever
was discussed beyond the ticket comments, or anything else I've found
yet.

So once again, in summary, I'd like to petition for something of a
conclusive decision about file deletion, this time on the above-noted
patch.  The ticket comments mention that it would be too late for
introducing a feature like that into the development cycle, but that
looks like it was from the 1.1 days.  I don't want something like this
to slip beyond the end of December, and then have it ignored until a
1.3-ish release.

It looks like Jacob had the eyes that looked over the ticket last
significant update.  Any thoughts, Jacob or anyone else?

Tim

[1] http://code.djangoproject.com/ticket/7048

On Nov 21, 6:18 pm, Alexander Schepanovski  wrote:
> I agree, currently I am deleting old file in view handling form, which
> does not feel right. I also need to check for upload errors and in
> case of ImageField if it's a valid image, which feels really wrong
> since the field is doing it on itself

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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=.

How hard would it be to make bits of Django compatible with async servers?

[Simon Willison]

I've been getting very excited about Node.js recently:

http://simonwillison.net/2009/Nov/23/node/

It's basically Twisted / Tornado but in JavaScript, and with the huge
advantage that, because it's brand new, it doesn't have any legacy
blocking APIs. Database access looks like this:

c.query("select * from articles").addCallback(function(rows) {
  pretty_print(rows);
});

Even filesystem access is non-blocking:

posix.cat("/etc/passwd").addCallback(function(content) {
  puts(content);
});

This made me think about non-blocking IO and Django. Theoretically,
many of the services that Django provides could be used in a non-
blocking environment such as that provided by Twisted or Tornado:

* URL routing shouldn't need to be blocking - it's just dispatching to
a function based on a regex (though this is stymied by thread locals)
* Form handling shouldn't need to block on I/O
* If we cache templates in memory instead of reading from disk each
time, rendering them shouldn't need to block on IO either
* SQL statement generation with the ORM shouldn't need to block either

That last one is particularly interesting to me. My understanding is
that much of the ORM refactoring for multi-db consisted of improving
the separation of SQL generation from actual database interaction.
Being able to do something like this would still be incredibly useful:

def my_async_view(request, response):
query = Blog.objects.filter(pubdate__year = 2009).exclude
(tag__slug = 'sport')
def done(rows):
response.render('blog.html', {'rows': rows})
db.execute_async(query, done)

The db.execute_async method would take a queryset and a callback,
execute the query asynchronously and pass the result to that callback.
I've invented an imaginary potential async replacement for the
blocking response=view(request) idiom.

I don't think async support should be baked in to Django core, but
it's a very interesting thing to think about. Should we eventually
break Django up in to smaller reusable libraries this kind of thing
would be an exciting use case.

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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=.

Re: Problem with history view in admin page

[Karen Tracey]

Note Oracle had the same problem:

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

I can't actually read Oracle but I think the fix involves adding a cast that
extracts the first 4000 chars of data from the field for comparison.  They
override the field_cast_sql method in the Oracle DatabaseOperations to add
the cast to any field type that ends with LOB.

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-develop...@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=.

Re: Problem with history view in admin page

[Russell Keith-Magee]

On Mon, Nov 23, 2009 at 9:12 PM, Rahul  wrote:
> Hi All,
>
> There is a problem reported for history view in admin page.
> For history view there is a sql query generated, which trying to do
> exact look-up on OBJECT_ID column (LogEntry model, DJANGO_ADMIN_LOG
> table).
>
> "TextField" is responsible for handling large text and in DB2
> "TextField" is mapped to CLOB.
> DB2 doesn't support exact look-up with CLOB datatype.
>
> When I checked the values for this OBJECT_ID column in the database,
> it only contains integer (1, 2, 3, etc.).
>
> Now the question arises: Why "OBJECT_ID" defined as "TextField" type?
> In most of the cases "XXX_ID" field is expected to be INTEGER.
>
> Is there any specific reason why "OBJECT_ID" defined as "TextField" in
> LogEntry model in "django\contrib\admin\models.py".

Yes.

The reason is that while *most* objects will use an integer as the
primary key, not *all* objects use an integer as a primary key. A
TextField is the most generic storage that can be  provided to store
*any* kind of primary key - integer, char, or otherwise. What is
stored in this field is a string-serialized representation of the
primary key value.

LogEntry.get_edited_object then issues the query to find the actual
object that is associated with the id; this relies on the fact that
Django queries will coerce string input into an appropriate data type
for a primary key lookup.

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-develop...@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=.

Problem with history view in admin page

[Rahul]

Hi All,

There is a problem reported for history view in admin page.
For history view there is a sql query generated, which trying to do
exact look-up on OBJECT_ID column (LogEntry model, DJANGO_ADMIN_LOG
table).

"TextField" is responsible for handling large text and in DB2
"TextField" is mapped to CLOB.
DB2 doesn't support exact look-up with CLOB datatype.

When I checked the values for this OBJECT_ID column in the database,
it only contains integer (1, 2, 3, etc.).

Now the question arises: Why "OBJECT_ID" defined as "TextField" type?
In most of the cases "XXX_ID" field is expected to be INTEGER.

Is there any specific reason why "OBJECT_ID" defined as "TextField" in
LogEntry model in "django\contrib\admin\models.py".

The original post of this problem is available on
http://groups.google.com/group/ibm_db/browse_thread/thread/368e5739eb358e20

Regards,
Rahul Priyadarshi

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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=.

Re: Public method for getting model field names in order of definition

[Anssi Kaariainen]

Here is a working example. I am using svn version of Django, but IIRC
this works also in 1.0.

views.py:

from django.shortcuts import render_to_response
from django import forms

class Example(forms.Form):
field1 = forms.CharField()
field2 = forms.IntegerField(label='Labeled')

def view(request):
data = {'field1': 'Foo', 'field2': 10}
form = Example(data=data)
return render_to_response('t.html', {'form': form})

t.html:

{% for field in form %}
  {{ field.label }}{{field.data}}
{% endfor %}



On Nov 23, 2:14 am, Richard Laager  wrote:
> On Sat, 2009-11-21 at 05:57 -0800, Anssi Kaariainen wrote:
> > If I am not completely mistaken you can use your ModelForm with
> > field.label and field.data to get read-only view of the model.
>
> I was trying to do something like this today and didn't have any luck.
> Do you have a pointer to a working sample?
>
> Richard
>
>  signature.asc
> < 1KViewDownload

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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=.

#12202 (Hardcoded subject in the reset password mail)

[Austin Gabel]

I'm needing a bit of feedback on this ticket[1].  Currently there is no way
to specify what the subject line of a password reset email should contain.
SmileyChris brought up the question of whether to pass this subject as an
argument in the view/form or to use a template.  In the patch I have added
to the ticket, I have taken the template route.  I would like to know if
there is a precedence for an issue like this, and if I'm on track or way off
base. Keep in mind I'm a newbie around here so be gentle.


[1] http://code.djangoproject.com/ticket/12202

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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=.