Re: PATCH: Limit 100 default in frmEditGrid.cpp

I propose a small patch to frmEditGrid.cpp that changes the default limit
form "No limit" to "100 rows".

Another option, more coherent in design to the rest of the program, can be
disabling automatic run and let the user configure the option before. I
think there are a small number of forms that are performing long operation
at the show time without the explicit user action.

Besides usability, the problem I found is a segfault happening when the
table is huge (mine is 14e6 records) and the frmEditGrid is closed before
the load is complete. In my configuration the crash is reproducible with
version 1.8.4 and trunk.

Cheers,
Matteo Bertini

On Sat, Jan 10, 2009 at 1:58 AM, Matteo Bertini <matteo(at)naufraghi(dot)net> wrote:
> I propose a small patch to frmEditGrid.cpp that changes the default limit
> form "No limit" to "100 rows".

I'm not sure that's something we want to change - I don't recall it
ever being requested before, and personally I think I'd find it
annoying.

What I would be happier with is a drop-down menu on the View Data
button which gave access to the different options as the context menu
does. The button itself would then run the last option selected from
the drop-down menu (exactly as the plugins button does).

> Another option, more coherent in design to the rest of the program, can be
> disabling automatic run and let the user configure the option before. I
> think there are a small number of forms that are performing long operation
> at the show time without the explicit user action.

Eh? There s an explicit user action - you clicked 'View Data'

> Besides usability, the problem I found is a segfault happening when the
> table is huge (mine is 14e6 records) and the frmEditGrid is closed before
> the load is complete. In my configuration the crash is reproducible with
> version 1.8.4 and trunk.

Can you get a backtrace from the crash?

--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com

On 12-01-2009 10:49, Dave Page wrote:
> On Sat, Jan 10, 2009 at 1:58 AM, Matteo Bertini<matteo(at)naufraghi(dot)net> wrote:
>
>> I propose a small patch to frmEditGrid.cpp that changes the default limit
>> form "No limit" to "100 rows".
>>
> I'm not sure that's something we want to change - I don't recall it
> ever being requested before, and personally I think I'd find it
> annoying.
>
What is your use case for no limit? I use the view just for:
1) check/modify a few records (<< 1000)
2) have a look at the data in one click
Both of this use cases are not influenced by a default limit (let's say
500, even 1000, but << infinity)
> What I would be happier with is a drop-down menu on the View Data
> button which gave access to the different options as the context menu
> does. The button itself would then run the last option selected from
> the drop-down menu (exactly as the plugins button does).
>
Yes, the "promoted" option and the last-selected config are a good for me.
>> Another option, more coherent in design to the rest of the program, can be
>> disabling automatic run and let the user configure the option before. I
>> think there are a small number of forms that are performing long operation
>> at the show time without the explicit user action.
>>
> Eh? There s an explicit user action - you clicked 'View Data'
>
Yes and no, that is the only button can cause a long action without
further user action, all the other buttons are 1) immediate 2) are
showing a form for further config.
>> Besides usability, the problem I found is a segfault happening when the
>> table is huge (mine is 14e6 records) and the frmEditGrid is closed before
>> the load is complete. In my configuration the crash is reproducible with
>> version 1.8.4 and trunk.
>>
> Can you get a backtrace from the crash?
>
Something like this? (I reconfigured pgadmin3 with --enable-debug)

(gdb) run
Starting program: /home2/bertini/src/pgadmin3/pgadmin/pgadmin3
[Thread debugging using libthread_db enabled]
[New process 14512]
[New Thread -163538160 (LWP 14512)]
[New Thread -168051824 (LWP 14693)]
[Thread -168051824 (zombie) exited]
[New Thread -176501872 (LWP 14694)]

<actions>
Choose a big table,
click on view,
close the windows before the data is ready
</actions>

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -176501872 (LWP 14694)]
0x091792c0 in ?? ()
(gdb) bt
#0 0x091792c0 in ?? ()
#1 0xf687014c in BIO_read () from /usr/lib/i686/cmov/libcrypto.so.0.9.8
#2 0xf693ac3e in ssl3_read_n () from /usr/lib/i686/cmov/libssl.so.0.9.8
#3 0xf693b045 in ssl3_read_bytes () from /usr/lib/i686/cmov/libssl.so.0.9.8
#4 0xf69389a6 in ssl3_read () from /usr/lib/i686/cmov/libssl.so.0.9.8
#5 0xf694a96f in SSL_read () from /usr/lib/i686/cmov/libssl.so.0.9.8
#6 0xf72a0e3d in pqsecure_read () from /usr/lib/libpq.so.4
#7 0xf7299427 in pqReadData () from /usr/lib/libpq.so.4
#8 0xf72971ac in PQconsumeInput () from /usr/lib/libpq.so.4
#9 0x080dc421 in pgQueryThread::execute (this=0x8fc1500) at
./db/pgQueryThread.cpp:113
#10 0x080dc92d in pgQueryThread::Entry (this=0x8fc1500) at
./db/pgQueryThread.cpp:197
#11 0xf7523896 in wxThreadInternal::PthreadStart (thread=0x8fc1500)
at ../src/unix/threadpsx.cpp:766
#12 0xf752399d in wxPthreadStart (ptr=0x8fc1500) at
../src/unix/threadpsx.cpp:718
#13 0xf7157f3b in start_thread () from /lib/libpthread.so.0
#14 0xf70deb6e in clone () from /lib/libc.so.6
(gdb)

Matteo Bertini a écrit :
> On 12-01-2009 10:49, Dave Page wrote:
>> On Sat, Jan 10, 2009 at 1:58 AM, Matteo Bertini<matteo(at)naufraghi(dot)net>
>> wrote:
>>
>>> I propose a small patch to frmEditGrid.cpp that changes the default
>>> limit
>>> form "No limit" to "100 rows".
>>>
>> I'm not sure that's something we want to change - I don't recall it
>> ever being requested before, and personally I think I'd find it
>> annoying.
>>

I do too. Modifying this behavior would disturb many current users.

> What is your use case for no limit? I use the view just for:
> 1) check/modify a few records (<< 1000)
> 2) have a look at the data in one click
> Both of this use cases are not influenced by a default limit (let's say
> 500, even 1000, but << infinity)

I agree with you on this. But I would prefer to see some controls to
enable pagination.

>> What I would be happier with is a drop-down menu on the View Data
>> button which gave access to the different options as the context menu
>> does. The button itself would then run the last option selected from
>> the drop-down menu (exactly as the plugins button does).
>>
> Yes, the "promoted" option and the last-selected config are a good for me.

+1

--
Guillaume.
http://www.postgresqlfr.org
http://dalibo.com

On Mon, Jan 12, 2009 at 10:50 AM, Matteo Bertini <matteo(at)naufraghi(dot)net> wrote:

> What is your use case for no limit? I use the view just for:
> 1) check/modify a few records (<< 1000)
> 2) have a look at the data in one click
> Both of this use cases are not influenced by a default limit (let's say 500,
> even 1000, but << infinity)

There are, because if you set an arbitrary default to (say) 100, then
every time I want to look at a table with 127 rows I have to run the
query twice. The only way to avoid that is to set a higher arbitrary
limit, but as we've heard numerous times in the past, different people
have different ideas about how many records they regularly view in the
tool.

>> What I would be happier with is a drop-down menu on the View Data
>> button which gave access to the different options as the context menu
>> does. The button itself would then run the last option selected from
>> the drop-down menu (exactly as the plugins button does).
>>
>
> Yes, the "promoted" option and the last-selected config are a good for me.

I think that would meet everyones needs with the least amount of pain.
Can you work up a patch?

> Yes and no, that is the only button can cause a long action without further
> user action, all the other buttons are 1) immediate 2) are showing a form
> for further config.

I think the usability benefits of being able to View Data without
having to open the window and then click another button out-weigh any
perceived inconsistency.

> Something like this? (I reconfigured pgadmin3 with --enable-debug)

Yup - just like that :-). It seems to be crashing with OpenSSL's code.
Do you see the same issue on a non-SSL connection?

/D

--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com