Обсуждение: Step ordering pgAgent
Hi,
I'm starting another thread for this topic. You'll find the last comment from Dave at the bottom.
> 1. Step ordering
> I suggest adding a column named "jstorder" to pgagent.pga_jobsteps, so
> we don't have to rename the steps "A_", "B_" if an ordering is required. In
> the GUI we would add an integer field to the "Change Step" mask.
> I suggest adding a column named "jstorder" to pgagent.pga_jobsteps, so
> we don't have to rename the steps "A_", "B_" if an ordering is required. In
> the GUI we would add an integer field to the "Change Step" mask.
> Hi,
> I'm not so keen on that - it could require some funky code to ensure
> that the user uses sequential (or at least, non-duplicate) numbers
> across all steps and would be a pain to upgrade to. Plus, there is
> precedence for using alpha ordering - that's how triggers work
> that the user uses sequential (or at least, non-duplicate) numbers
> across all steps and would be a pain to upgrade to. Plus, there is
> precedence for using alpha ordering - that's how triggers work
>> I don't think that we must ensure that no duplicate values are used. With
>> changing the "order by jstname,jstid" clause to "order by
>> jstorder,jstname,jstid" we would have a fall back on alpha ordering.
>> Steps with "jstorder" = null would be executed last - so there is no need to
>> upgrade. To give the user feedback about ordering in pgadmin, the steps
>> could be ordered the same way in tree view and steps tab in job properties
>> dialog. We could also add the jstorder-column to the list view.
it certainly will become inconsistent with triggers.
On Fri, Dec 31, 2010 at 15:38, Jasmin Dizdarevic <jasmin.dizdarevic@gmail.com> wrote: > Hi, > I'm starting another thread for this topic. You'll find the last comment > from Dave at the bottom. >> 1. Step ordering >> I suggest adding a column named "jstorder" to pgagent.pga_jobsteps, so >> we don't have to rename the steps "A_", "B_" if an ordering is required. >> In >> the GUI we would add an integer field to the "Change Step" mask. >> Hi, >> I'm not so keen on that - it could require some funky code to ensure >> that the user uses sequential (or at least, non-duplicate) numbers >> across all steps and would be a pain to upgrade to. Plus, there is >> precedence for using alpha ordering - that's how triggers work >>> I don't think that we must ensure that no duplicate values are used. With >>> changing the "order by jstname,jstid" clause to "order by >>> jstorder,jstname,jstid" we would have a fall back on alpha ordering. >>> Steps with "jstorder" = null would be executed last - so there is no need >>> to >>> upgrade. To give the user feedback about ordering in pgadmin, the steps >>> could be ordered the same way in tree view and steps tab in job >>> properties >>> dialog. We could also add the jstorder-column to the list view. > > What do others think? I'm still not convinced this is necessary - and > it certainly will become inconsistent with triggers. I think having explicit ordering would be good. For one thing, step ordering based on alphanumerics can actually differ depending on the servers locale, which is a receipie for "interesting bug reports". But it's certainly not *necessary* - we haven't had any such bug reports bubble up to this level (if it has happened to people they figured it out and solved it themeslves), and there is the trigger consistency. OTOH, triggers are actual database objects, so I think poeple are likely to make more restricted choices in naming them. And TBH, most installs will not have more than one trigger per table. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
Why is the trigger consistency so important for you? In my opinion triggers have nothing to do with job steps. Other agent implementations (e.g. sqlagent) also provides the ability to reorder steps.
Magnus, you're right there is no bug report on it. Could a reason for that be that pgAgent isn't used on much installations?
.
2010/12/31 Magnus Hagander <magnus@hagander.net>
I think having explicit ordering would be good. For one thing, stepOn Fri, Dec 31, 2010 at 15:38, Jasmin Dizdarevic
<jasmin.dizdarevic@gmail.com> wrote:
> Hi,
> I'm starting another thread for this topic. You'll find the last comment
> from Dave at the bottom.
>> 1. Step ordering
>> I suggest adding a column named "jstorder" to pgagent.pga_jobsteps, so
>> we don't have to rename the steps "A_", "B_" if an ordering is required.
>> In
>> the GUI we would add an integer field to the "Change Step" mask.
>> Hi,
>> I'm not so keen on that - it could require some funky code to ensure
>> that the user uses sequential (or at least, non-duplicate) numbers
>> across all steps and would be a pain to upgrade to. Plus, there is
>> precedence for using alpha ordering - that's how triggers work
>>> I don't think that we must ensure that no duplicate values are used. With
>>> changing the "order by jstname,jstid" clause to "order by
>>> jstorder,jstname,jstid" we would have a fall back on alpha ordering.
>>> Steps with "jstorder" = null would be executed last - so there is no need
>>> to
>>> upgrade. To give the user feedback about ordering in pgadmin, the steps
>>> could be ordered the same way in tree view and steps tab in job
>>> properties
>>> dialog. We could also add the jstorder-column to the list view.
>
> What do others think? I'm still not convinced this is necessary - and
> it certainly will become inconsistent with triggers.
ordering based on alphanumerics can actually differ depending on the
servers locale, which is a receipie for "interesting bug reports".
But it's certainly not *necessary* - we haven't had any such bug
reports bubble up to this level (if it has happened to people they
figured it out and solved it themeslves), and there is the trigger
consistency. OTOH, triggers are actual database objects, so I think
poeple are likely to make more restricted choices in naming them. And
TBH, most installs will not have more than one trigger per table.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
On Mon, Jan 3, 2011 at 19:08, Jasmin Dizdarevic <jasmin.dizdarevic@gmail.com> wrote: > Why is the trigger consistency so important for you? In my opinion triggers > have nothing to do with job steps. Other agent implementations (e.g. > sqlagent) also provides the ability to reorder steps. > Magnus, you're right there is no bug report on it. Could a reason for that > be that pgAgent isn't used on much installations? Yes, that would be my guess. I haven't come across many installations in the wild myself. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
On Mon, Jan 3, 2011 at 6:08 PM, Jasmin Dizdarevic <jasmin.dizdarevic@gmail.com> wrote: > Why is the trigger consistency so important for you? Consistency is critical to ease of use in any kind of application. If there are different techniques used to accomplish similar tasks, then it reduces the intuitiveness of the user interface which can lead to user confusion. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
I'm with you about the ease of use, but I don't agree that triggers and jobs are so near to each other. In my opinion there is at least a functional difference: Triggers are needed on application level and are maintained by a developer. Jobs are helpers for database admins to keep the database "clean" or to update data (data cumulation, definition updates,...).
But we can discuss this topic later, if it's requested by more users.
Jasmin
2011/1/3 Dave Page <dpage@pgadmin.org>
On Mon, Jan 3, 2011 at 6:08 PM, Jasmin Dizdarevic<jasmin.dizdarevic@gmail.com> wrote:> Why is the trigger consistency so important for you?Consistency is critical to ease of use in any kind of application. If
there are different techniques used to accomplish similar tasks, then
it reduces the intuitiveness of the user interface which can lead to
user confusion.
--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company