none, also if it seems that in trunk name is not required anymore to be unique.
On 11 Ago, 11:21, Massimo Di Pierro <[email protected]> wrote: > You are the second person to point it out. I am ok to change it. Any > third opinion? > > Massimo > > On Aug 11, 2:14 am, G <[email protected]> wrote: > > > > > > > > > Hello, > > I wonder what the intent of the task_scheduled.name field is in the > > new scheduler.py. Specifically, why is it required that it be unique? > > I see two disadvantages and no advantage, so I'm wondering what I'm > > missing. > > The first, and most important, disadvantage is that when > > programatically submitting tasks, one must come up with unique names. > > This isn't hard (using the time etc.) but seems pointless. > > > Second, in my application, the user can submit tasks to the server. > > I'd like to give the tasks a user friendly name that is displayed when > > the user monitors the status of the tasks. I thought the name field > > would be ideal for this, but if the user wants to submit two of the > > same type of task, the name would conflict unless it has something > > appended to it to make it unique. The "something appended" detracts > > from the user freindlyness of the field. I could solve this by adding > > another table that refrences task_scheduled and holds the user > > friendly name. > > > I'm wondering if the intent is to prevent duplicate task submission, > > but it seems more logical to me to allow multiple task submission and > > have the user avoid it if necessary rather than making the DB enforce > > a rule that requires a workaround to enable multiple task submissions. > > > Thanks, > > G
