Topics

Roster Entry ID question

Dan Boudreau
 

Why doesn't JMRI automatically create the roster entry id for a new loco?  Why do we ask the user to create it?

I propose that we should automatically provide a roster id for a new loco, but still allow the user to change it if they wish.

Dan

Robert Middleton
 

Is there a particular reason that this is changeable anyway?  My club has a large list of locomotives from all members, and while I don't think that we've had problems with duplicates it seems to me that just guessing what the ID should be is counter-producitve, since you could easily come up with duplicates in this situation(50+ members, assuming they all have 10 locomotives that they put in that is at least 500 roster entries).  Is the ID supposed to be the same thing as a PRIMARY KEY in SQL?

-Robert Middleton

On Fri, Jan 4, 2019 at 9:12 PM Dan Boudreau <daboudreau@...> wrote:
Why doesn't JMRI automatically create the roster entry id for a new loco?  Why do we ask the user to create it?

I propose that we should automatically provide a roster id for a new loco, but still allow the user to change it if they wish.

Dan

Paul Bender
 



On Friday, January 4, 2019, Dan Boudreau <daboudreau@...> wrote:
Why doesn't JMRI automatically create the roster entry id for a new loco?  Why do we ask the user to create it?

I propose that we should automatically provide a roster id for a new loco, but still allow the user to change it if they wish.

So, let me just make sure I understand the proposal.....

You want JMRI to automatically generate a unique string for the roster ID instead of putting <new locomotive> ( or whatever the text says now... doing this from memory and I haven’t payed attention to that for a while. )  so the user can just hit save as soon as they open the entry.

If that’s the case, I think we need a method similar *nix mktemp method ( for C/C++)

Paul

db123@bergqvist.se
 

2019-01-05 16:02 skrev Paul Bender:
If that’s the case, I think we need a method similar *nix mktemp
method ( for C/C++)
http://man7.org/linux/man-pages/man3/mktemp.3.html
A similar method in Java is:
java.io.File.createTempFile(String prefix, String suffix, File directory)

https://www.tutorialspoint.com/java/io/file_createtempfile_directory.htm
https://docs.oracle.com/javase/7/docs/api/java/io/File.html#createTempFile(java.lang.String,%20java.lang.String,%20java.io.File)

Daniel

Paul Bender
 

On Jan 5, 2019, at 12:15 PM, "db123@..." <db123@...> wrote:

2019-01-05 16:02 skrev Paul Bender:
If that’s the case, I think we need a method similar *nix mktemp
method ( for C/C++)
http://man7.org/linux/man-pages/man3/mktemp.3.html
A similar method in Java is:
java.io.File.createTempFile(String prefix, String suffix, File directory)

https://www.tutorialspoint.com/java/io/file_createtempfile_directory.htm
https://docs.oracle.com/javase/7/docs/api/java/io/File.html#createTempFile(java.lang.String,%20java.lang.String,%20java.io.File)
True, but that. Actually created the file, it doesn’t just give you the name.

The only real problem with that is if the user decides not to save, or to provide their own roster I’d, you have to clean up the empty file. The C method I referenced only provides the name as a string.

Paul

Bob Jacobsen
 

Well, this thread went entirely sideways.

The issue isn’t how to make a unique-and-arbitrary new ID. There are lots of _simple_ ways to do that (ahem; the lowest integer number that isn’t already used as an ID comes to mind)

The ID is the _user_ _visible_ name for the Locomotive. It’s how they select them in the roster in many cases. Why would making up something arbitrary be at all useful to people? “Cool! Now I can just click save and never be able find this one again!” doesn’t seem like a selling point.

The behavior now requires the user to _name_ their new locomotive. What, exactly, is the problem with that?

“Dad, why am I called rPoCJjKirtaiu?”
“Well, son, names are automatically generated at birth, and I never bothered to read the instructions about how to change yours.”

Bob
--
Bob Jacobsen
@BobJacobsen

Paul Bender
 

On Jan 5, 2019, at 2:25 PM, Bob Jacobsen <@BobJacobsen> wrote:
The ID is the _user_ _visible_ name for the Locomotive. It’s how they select them in the roster in many cases. Why would making up something arbitrary be at all useful to people? “Cool! Now I can just click save and never be able find this one again!” doesn’t seem like a selling point.
I initially had that same reaction when I read Dan’s suggestion. But then I realized that as long as some of the identification information is filled in, the initial roster screen provides enough information to find the entry.

The behavior now requires the user to _name_ their new locomotive. What, exactly, is the problem with that?
I don’t really think there is anything wrong with that. The user has to put in some identification to avoid loosing the roster entry.

Paul

Dan Boudreau
 

Bob, thanks for answering my question,

I was looking for the reason why we allow a user to create an id.  The help doesn't explain it properly, your explanation sheds some light, and makes sense.  But it also seems to me that a user would look up a loco by its DCC address, or by its road name and number.  When I was asked to create an id when creating a new entry, I entered "1", not very useful, but I also did not understand why it should be anymore than a simple numbers or letters.  The help does not explain how a good "id" or name might be useful.

Still, I could see hiding the id field completely and making things more simple for everyone.

It would also be interesting to see what strings our users have created for a loco id when making a new entry.

The US government gave me a unique id (SSN#) when I was born, I don't see why we can't do the same.

Happy new year,

Dan

RadSolution
 

I think the issue is with nomenclature-

The term ID is, IMHO, being misused here.

Generating a unique ID at creation is fine; it happens all the time in database rows.

Creating a user-used value automatically at creation is fraught with difficulties.
This value shouldn’t be called an ID.

Just my take on it....

Dan Boudreau
 

I'm not saying we should eliminate the "Id" field, but make it optional and allow the user to name a roster entry anything they want, or not.  I also agree if we automatically created a unique roster id for the user, that the "Roster id" could be changed to something like "Roster Name".

Dan

Randall Wood
 

I've been at a modular club where members bring their own equipment and have seen situations where the combination of DCC Address+Road Name+Road Number+Mfg+Decoder Model is not unique (the only meaningful distinguishing characteristics in the JMRI roster are Owner Name and ID), so hiding the user input unique ID in the user interface would present real issues for some users.

In ~7 years at this club with an average of 3 setups per month we've only had two engines with same address from different owners on the layout at the same time twice and only once was it an unanticipated issue (the other time the two owners had coordinated that for a double header).

Bob Jacobsen
 

The ID (as it’s now called) is the way that people select roster entries in the throttle, the consist tool, when doing edit/copy/delete/export via the Roster menu in PP, in Layout Editor, Dispatcher and Memory/Block train tracking. Users interact via the entry ID on some hardware systems (ECoS, RPS, others?) and web services.

It might be fine to change from calling it “ID” to “name”. It’s a lot of occurrences, particularly in the documentation images, but if that’s significantly clearer that’s perhaps it’s worth it. Maybe do a poll on jmriusers to see?

Improving the tooltip (which remarkably few people ever see, and fewer read) and window help page (which was mentioned earlier, so _did_ get read) would be good. See https://github.com/JMRI/JMRI/pull/6402

But doing away with something that’s used by lots and lots of people, or even worse turning it into some weird auto-string out of a false equivalence to the normalization rules of database primary keys, seems to indicate a significant loss of perspective.

Both this list and jmriusers seem to have forgotten that thousands, perhaps over 10.000 people use these things and most of those people basically understand it.

Yes, when we can simplify the language we should.

But “it has a name” is a simple concept that people can deal with.[1]

Making all this more complicated is a win for who, exactly? (That’s not a rhetorical question, I’d really like to know)

Bob


[1] Two side points on that:

- No, in the US, you are _not_ given a unique ID (SSN) when you are born. You (more specifically, your parents) have to ask for it. And you must _first_ have a name: https://www.ssa.gov/pubs/EN-05-10023.pdf

- Berkeley gives people on campus three different unique numbers: There s a student record number (10 digits), a computer-account UID (7 digits) and an ID card number (14 digits). Yet we still talk to and with each other using names. People like using names. They even like to be able to modify their names so they work better: Bob instead of Robert for example.

--
Bob Jacobsen
@BobJacobsen

Dan Boudreau
 

Bob,

You made an excellent point of why the roster id needs to be unique and readable.

I was attempting to write a script to import a list of locos from a spreadsheet and stumbled on the loco id requirement when creating a new entry. I just wasn't sure what a good roster id should look like to guarantee uniqueness.

BTW, the DecorderPro manual help is much better than the window's bar help with regards to the roster id / name. If I had looked there first I might not have asked the question.

Sorry about that, and thanks for the insight.

Dan

Paul Bender
 

On Jan 6, 2019, at 11:53 AM, Bob Jacobsen <@BobJacobsen> wrote:
But doing away with something that’s used by lots and lots of people, or even worse turning it into some weird auto-string out of a false equivalence to the normalization rules of database primary keys, seems to indicate a significant loss of perspective.
After thinking about this for a couple of days, I can justify the automatic creation of the ID, but only for the case where a single user is involved who only programs decoders.

As soon as a user starts using any of the tools that use a roster selection widget other than the main roster screen to select an entry, we loose the ability to see all the other fields involved. Using a random ID only increases the memory load for the user, which is not good for user friendliness.

Frankly, I think this would become a support nightmare, and I am not in favor of actually making any operational change.


I see the potential change from ID to Name as isomorphic. I would strongly prefer to retain using the term ID, which has served us well for as long as I have been involved in the project ( 16 or 17 years now... )

Paul