Re: Non-trivial question: New subclass companion for Stacked/Tabular Inlines

[Tim]

I'm aware that the admin-ui branch is to be folded into the 1.2
release of Django-- I'm not very familiar with the branch, and
docmentation is hard to find on it (in my opinion), short of running
the branch myself.  Will it replace the need for the current
InlineModelAdmin subclasses entirely?  I know that I can just go try
the branch myself, but that's a bit of a sidequest for just wanting
inlines to stop running off the side of the page :)

Looking forward to the implementations of the things pointed out
here.  Conclusively, there's only a very diminished need for
alternative InlineModelAdmin subclasses, until 1.2 graces us with some
new approaches.

Tim

On Nov 8, 10:44 am, andybak  wrote:
> I'm pretty sure Zain has made all the inline types sortable on his
> admin-ui branch.
>
> On Nov 8, 7:58 am, Tim  wrote:
>
>
>
> > I very much like the look of that one, but I'm not sure if it
> > completely fills the need I want for my own project.  All of the
> > fields need to be quickly visible, without needing to know the
> > rendered name of the instance.
>
> > Those 'new inlines' address the problem of space, but they cater to
> > those who already know what they're looking for.  My coworkers need to
> > constantly look over lists of location addresses, and require that all
> > the fields are displayed for quick scanning.  In other words, the
> > users of this particular admin page will rely very heavily on it to
> > show them all the data at all times.
>
> > Another improvement to inlines in general would be to make them
> > sortable.  There are some Javascript enhancements out there for
> > sorting HTML tables by any column, by clicking on its  tag.  The
> > 'new inlines' don't really allow for this possibility.
>
> > (I did make a simple app out of the 
> > TiledInline:http://code.google.com/p/django-tiledinline/)
>
> > Again, thanks for the feedback!  I should play more with those new
> > inlines.  I really do think that there is potential there, as with
> > most of the wonderful things that come from GSoC.
>
> > Tim
>
> > On Nov 7, 5:23 am, Renato Garcia Pedigoni 
> > wrote:
>
> > > Hi Tim
>
> > > Wouldn't be the 'new inlines'  [1] of GSoC admin improvements a nice
> > > approach? The height is fixed, no waste of space... And no need to have
> > > blank fieldsets for new objects (the 'extra' inline option).
>
> > > But anyway sometimes Stacked and Tabular just don't fit, it's nice to have
> > > another way to show related objects.
>
> > > [1]http://media.wilsonminer.com/images/django/related-objects-stacked.gif
>
> > > Renato
>
> > > On Fri, Nov 6, 2009 at 11:59 PM, Tim  wrote:
>
> > > > On Nov 6, 6:20 pm, Alex Gaynor  wrote:
> > > > > This sounds interesting, but I'm having a hard time visualizing it,
> > > > > any chance you could provide some screenshots?
>
> > > > Absolutely.  I wrote up a blog post about it today:
> > > >http://mangos.dontexist.net/blog/?p=352
>
> > > > There are a couple of screenshots listed there.
>
> > > > I truly find this most useful when dealing with TextFields, like I
> > > > mention in the blog post, because if you get 5 or 6 of those together,
> > > > they get really wide really fast, and neither the Stacked nor Tabular
> > > > really suits the situation, in terms of usability.
>
> > > > > As for whether it
> > > > > should be included I'd say the first step is to get it out there in an
> > > > > app anyone can download, as things like this can live outside of
> > > > > Django.
>
> > > > Yeah, with the blog post there is a zip file download.  It's not
> > > > really in an "app" form, but that can be done fairly easily.  I shall
> > > > put one together, for the sake of getting it working as close to zero-
> > > > config as possible.
>
> > > > Thanks much for the reply.  Glad to hear some interest.
>
> > > > Tim
>
> > > > > Second, if you are serious about getting this included in
> > > > > Django I'd file a bug and upload a patch, it's much easier to discuss
> > > > > these things when there's something concrete on the table.
>
> > > > > 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
> > > > > "Code can always be simpler than you think, but never as simple as you
> > > > > want" -- Me
>
> > > --
> > > Atenciosamente,
> > > Renato Garcia Pedigoni
--~--~-~--~~~---~--~~
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: autocommit, INSERT... RETURNING and PostgreSQL 8.2+

[Christophe Pettus]

On Nov 8, 2009, at 8:39 AM, Seb Potter wrote:
> transaction pooling

Ah, of course.  Thank you!
--
-- Christophe Pettus
x...@thebuild.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: Non-trivial question: New subclass companion for Stacked/Tabular Inlines

[andybak]

I'm pretty sure Zain has made all the inline types sortable on his
admin-ui branch.

On Nov 8, 7:58 am, Tim  wrote:
> I very much like the look of that one, but I'm not sure if it
> completely fills the need I want for my own project.  All of the
> fields need to be quickly visible, without needing to know the
> rendered name of the instance.
>
> Those 'new inlines' address the problem of space, but they cater to
> those who already know what they're looking for.  My coworkers need to
> constantly look over lists of location addresses, and require that all
> the fields are displayed for quick scanning.  In other words, the
> users of this particular admin page will rely very heavily on it to
> show them all the data at all times.
>
> Another improvement to inlines in general would be to make them
> sortable.  There are some Javascript enhancements out there for
> sorting HTML tables by any column, by clicking on its  tag.  The
> 'new inlines' don't really allow for this possibility.
>
> (I did make a simple app out of the 
> TiledInline:http://code.google.com/p/django-tiledinline/)
>
> Again, thanks for the feedback!  I should play more with those new
> inlines.  I really do think that there is potential there, as with
> most of the wonderful things that come from GSoC.
>
> Tim
>
> On Nov 7, 5:23 am, Renato Garcia Pedigoni 
> wrote:
>
> > Hi Tim
>
> > Wouldn't be the 'new inlines'  [1] of GSoC admin improvements a nice
> > approach? The height is fixed, no waste of space... And no need to have
> > blank fieldsets for new objects (the 'extra' inline option).
>
> > But anyway sometimes Stacked and Tabular just don't fit, it's nice to have
> > another way to show related objects.
>
> > [1]http://media.wilsonminer.com/images/django/related-objects-stacked.gif
>
> > Renato
>
> > On Fri, Nov 6, 2009 at 11:59 PM, Tim  wrote:
>
> > > On Nov 6, 6:20 pm, Alex Gaynor  wrote:
> > > > This sounds interesting, but I'm having a hard time visualizing it,
> > > > any chance you could provide some screenshots?
>
> > > Absolutely.  I wrote up a blog post about it today:
> > >http://mangos.dontexist.net/blog/?p=352
>
> > > There are a couple of screenshots listed there.
>
> > > I truly find this most useful when dealing with TextFields, like I
> > > mention in the blog post, because if you get 5 or 6 of those together,
> > > they get really wide really fast, and neither the Stacked nor Tabular
> > > really suits the situation, in terms of usability.
>
> > > > As for whether it
> > > > should be included I'd say the first step is to get it out there in an
> > > > app anyone can download, as things like this can live outside of
> > > > Django.
>
> > > Yeah, with the blog post there is a zip file download.  It's not
> > > really in an "app" form, but that can be done fairly easily.  I shall
> > > put one together, for the sake of getting it working as close to zero-
> > > config as possible.
>
> > > Thanks much for the reply.  Glad to hear some interest.
>
> > > Tim
>
> > > > Second, if you are serious about getting this included in
> > > > Django I'd file a bug and upload a patch, it's much easier to discuss
> > > > these things when there's something concrete on the table.
>
> > > > 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
> > > > "Code can always be simpler than you think, but never as simple as you
> > > > want" -- Me
>
> > --
> > Atenciosamente,
> > Renato Garcia Pedigoni
>
>
--~--~-~--~~~---~--~~
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: autocommit, INSERT... RETURNING and PostgreSQL 8.2+

[Seb Potter]

Hi Christophe,

When you're running postgres with autocommit and transaction pooling (ie:
the lifetime of a connection is a single transaction - essential for
high-performance sites), you run the risk of returning an incorrect id by
calling:

cursor.execute("SELECT CURRVAL('\"%s_%s_seq\"')" % (table_name, pk_name)).

Because that select query would be running over a different connection.

INSERT ... RETURNING guarantees data integrity when returning the id
inserted by a transaction.

Seb Potter
http://www.woome.com/


2009/11/8 Christophe Pettus 

>
> Greetings,
>
> In looking around the code for the psycogp2 backend, it looks like
> autocommit is used, in part, as a checked assertion that the database
> being used is PG 8.2 or greater.  Comments lead me to believe that the
> reason that autocommit is limited to 8.2+ is that INSERT ... RETURNING
> was introduced into 8.2, and that syntax is required for correct
> operation while autocommit is True.  But I'm not sure I understand the
> reasoning; does anyone know why INSERT ... RETURNING is required in
> that case?
>
> Thanks!
> --
> -- Christophe Pettus
>x...@thebuild.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: #10509 (Better handling of database-specific information)

[Russell Keith-Magee]

On Sat, Nov 7, 2009 at 12:50 PM, Christophe Pettus  wrote:
>
> Greetings,
>
> As part of proposing a patch for a bug I filed (#12180), I ran across
> this ticket, and took the liberty of claiming it.  Since I'm
> relatively new to working on Django code proper, I wanted to start a
> discussion about possible approaches to solving these issues.
>
> I see two basic philosophical approaches:
>
> 1. The "safety razor" approach:  Django checks the version of the
> database server software, and either adapts its functionality to it or
> (at least) provides an early and explicit error, even at the cost of
> some performance.
>
> 2. The "straight razor" approach:  Django accepts any statements the
> user code makes about the database software at face value, and
> maximizes performance, accepting that the user being wrong will result
> in an obscure error at some random point.

As with all complex questions, the answer is "it depends". In this
case, it depends on exactly what you're asking the database to do, and
what API you're using to do it. I would characterise Django's approach
to database support as the following:

 1. Provide an abstracted, easily explainable API that can be used
across all databases

 2. When a particular API can't be implemented on a particular
database, fallback to a functioning, but downgraded version of
functionality described by the API (e.g., savepoints are a no-op under
MySQL)

 3. When functionality can't be downgraded gracefully, raise
Django-level generic errors early (e.g., Stdev aggregate/annotate
support for SQLite)

 4. Raise system-specific errors as a last resort, or when the end
user has access to internals.

"Obscure random errors" are rarely going to be desirable. It should be
difficult to use the API in the wrong way. If this means we need to
sacrifice a some efficiency in the name of providing a robust API to
end users, then so be it. However, we're also not going to wrap the
entire Django API in cotton wool and bubble wrap just to make sure
that nothing can ever break in an unexpected fashion. If the user is
tinkering with internals in an unusual way, or relying on the
specifics of a particular database, then the user should expect to see
some database-specific errors.

> Some specific things I'd like to accomplish:
>
> -- Allow Django to use the INSERT...RETURNING functionality of PG 8.2+
> even if autocommit isn't being used.
> -- Get rid of the need to repeatedly call SELECT version().
>
> Some other functionality that's not directly relevant to this ticket,
> but related and useful:
>
> -- Allow for Serializable transactions.
>
> Thoughts?

My thought is make a concrete suggestion, and/or "show us the patch" :-)

These issues aren't trivial to solve, and we're certainly open to
anyone that wants to take a serious swing at addressing them. However,
it's much easier to provide design guidance in the specific, rather
than the abstract.

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