Opened 9 years ago

Last modified 8 years ago

#264 new defect

Add code to keep identifying labels and descriptions unique

Reported by: dzollars Owned by: gegorbet
Priority: normal Milestone: future
Component: ultrascan3 Version:
Keywords: Cc:

Description

This is one thing I think we're going to have problems with continually with UltraScan III users. Currently in buffer, analyte, solution, and other places it is easy to have two or more identical labels or descriptions when the database ID's and the GUID's are different. A side effect is that a user can think he is working with a certain buffer or whatever when he isn't. Perhaps we should add some code somewhere to check for duplication in the label field and add a '(2)' or something afterwards.

Change History (6)

comment:1 Changed 9 years ago by dzollars

  • Status changed from new to assigned

I had originally thought that the most logical place to put such a thing was in the stored procedures. That could be done, however to implement fully it would involve some cumbersome string manipulation there. Another idea would be some kind of support routine that returns all the similar strings or something. Any thoughts?

comment:2 Changed 9 years ago by gegorbet

I think the code to add '(2)' [ or '(3)',... ] is a good idea.

A more general utility routine might be better than a stored procedure change. The same sort of modification of labels will be needed for local lists. Another issue to consider is whether this modification is to the actual label itself or just to the entry in a dialog list. You might have the same buffer by ID/GUID, for example, both in the DB and locally. If the local list had no duplicate label, then "TE buffer" might be better than "TE buffer (2)" even though that same buffer is listed as "TE buffer (2)" in a DB list.

We might want to have a 'bool modify_list( QStringList& ) ' method that changes any list component as necessary and returns true for any modifications; that way the GUI list element could be reloaded from the string list.

comment:3 follow-up: Changed 9 years ago by dzollars

I am thinking about a series of stored routines---one for buffers, one for solutions, etc. The buffer routine, for instance, could return a list of the current user's buffer descriptions matching a supplied pattern, like "New Buffer" or whatever. I guess we'd have to duplicate this in the various classes for disk mode.

Then I imagine a C++ utility function that calls the appropriate one of those and returns a modified string that is unique in that context. The new string could be used either for display or for saving and updating the buffer, but I think the latter is more desirable. That way the modified description would remain constant for the user. It should be possible for the user to rename these modified names, even swapping them. Also, for existing duplications the user could just resave them and create the new description.

It wouldn't be necessary to enforce uniqueness in these fields anywhere, though we could decide to do that if we wanted to. One thing that argues against doing that is going back and forth between disk and database mode.

Thoughts?

comment:4 in reply to: ↑ 3 Changed 9 years ago by demeler

Replying to dzollars:

Thoughts?

I think that the program should give an informational message:

A buffer called "chosen name" already exists. Do you want to
load that buffer and update its description?

Yes/No?

If the user clicks 'no', the program should request the user to enter a new name for this buffer.

The stored procedure could return a flag saying that the buffer already exists, and elicit the C++ program to output the
error message.

comment:5 Changed 9 years ago by gegorbet

I agree that at the time a user tries to enter what is a duplicate description, a dialog should force him to either modify the object with that name or chose a new name for any new object.

But there is the additional issue of lists that already include duplicate names. I would still favor having a utils routine that is purely list oriented. That is, regardless of a source of DB or local, each additional instance of a list object with the same entry would have a numeric in parenthesis added to the list entry ("(2)", "(3)", ...). If, for example, there were three unique buffers (by ID) with the name "water buffer". The lines in the list would be "water buffer", "water buffer (2)", "water buffer (3)".

The user might reasonably, at that point, decide to delete the first two buffers. The third one would now be listed as "water buffer". It's actual name in the DB or locally would never have changed, but the QStringList used for displaying entries would be referenced in a common utils routine that would respond to the fact that there now is only one "water buffer".

comment:6 Changed 8 years ago by gegorbet

  • Owner changed from dzollars to gegorbet
  • Status changed from assigned to new

As previously mentioned, the resolution of the duplicate label problem needs to be two-pronged.

(1) Disallow new entries with duplicate labels (force a unique label).

(2) Display lists with markings (e.g. " [2]") for duplicate labels.

I have studied code again recently and have a plan of attack that involves new Util routines to identify, count, and modify duplicate list entries and WidgetsDialog mods to both modify lists and disallow new entries with duplicate labels.

Note: See TracTickets for help on using tickets.