disappearing survey units (they're not there but their numbers are saved somehow)

[luizaogs]

My latest survey unit was 48. There is a unit 47 in Playground, but no others. Survey unit 40 actually exists in Providence as well. My question is: how is it that those units (41-6) are not there anymore if I am not able to delete them? Or at least, I don't know how to delete them. But their numbers are still definitely in the system somehow.

I do know that I created survey units in Playground in past weeks -- as far as I can remember that was one of the things I did when dealing with the #708 bug, for example. But I still don't get how they disappeared? I was looking through previous tickets to try and figure this out before bothering you with it, and #742 suggests to me that this is not a feature that is currently possible?

Anyway. Yikes. I really don't know how I manage to do these things.

(Is this a bug? I don't know.)

[urapadmin]

This sounds even like a horrible bug! I will look into synchronization logs and your last workstation upload right away.

[luizaogs]

It might be a Luiza-ism. But I'm not sure if you'll catch it looking at this latest one. I think survey unit 47 has been in Playground at least since last time. Argh.

[lbestock]

I have a suspicion that it is simpler than that.

Luiza, did you ever really create survey units 41-46?

Because feature unit number overlap seems to me a more obvious culprit. There is no F040. There is an F041, F042, etc, but not an F047....

[lbestock]

Those are the feature numbers assigned to Sam's iPad. What would happen if at the same time Sam created feature F040 and Luiza created Survey Unit 40? I had not anticipated that problem in creating identifier lists per workstation at all.

[luizaogs]

Ahh possible. I thought I had created some but I'm not sure, then. I had not realized that feature/unit number overlap could do that. Though it would depend on when the features were created? Survey unit 47 has been in there for a bit, I think.

[urapadmin]

I am puzzled.

[urapadmin]

well, there are definitely no survey units 41 to 46 in the file you last uploaded Also no 47. I have no access to older uploads, we don't keep a history.

There are feature units 41 to 46 but no 47 either.

[lbestock]

I think that the system is seeing "41-46 were already used somewhere" and so not creating a survey unit of those numbers for Luiza, even though her workstation has 40-49 as the assigned survey unit numbers. But the 41-46 were used by Sam as feature numbers (and he likewise has no F040 because Luiza had already created a survey unit F40).

But this is a potential problem for us - if I've gotten the reason right. It means I have set up the workstations in a way that potentially leads to a failure - it's pure luck that these two workstations have not created something with the same number on the same synchronization schedule, which would have been a disaster. It never even occurred to me when configuring that "feature numbers 1-99" in an overall configuration that gives a prefix to feature numbers would conflict with "survey numbers 40-49" - to me as the director F040 looks completely different than 40, used in different places, arrived at by different configuration methods.

[urapadmin]

I don't quite see how it could have lead to a disaster. The fact that this is so strict prevents exactly the disaster. The unit will not accept anything with the same local-id. And that is the running number behind those different methods of creating an identifier. I admit that this leads to, uhm, confusion but that's different from disaster. What am I not getting?

[urapadmin]

found 47. It is in the playground.

[urapadmin]

well, as Luiza told me to begin with. At least at this point I can support your hunch, it was right. If unit numbers have a numerical part that is auto generated, that numerical part has to be unique overall units. That is why you cannot create a unit 47 in playground and a unit 47 in another site. But it is also why you cannot generate 47 with one identification method and a 47 with another. In the end they all use the same numeric field to find out what the next number would be on creation of the next unit.

[lbestock]

The reason it could have been, well not a disaster - enough with the hyperbole - but a potentially significant problem, is that those two work stations could then have assigned the same number on the same day. Before synchronization, neither would have known that the number was used, and we would have lost one of the resulting units in synchronization, no? If Sam created feature F040 at the same time as Luiza created survey unit 40 they both would have input data but the system would not accept them both back.

Would it be possible to configure the ID method in a way where the F was not a prefix but a more integral part of the number? So that the range to the workstation was F001-F099, not 001-099?

I do really worry about this. I have much better understanding of configuration of this system than most directors will ever have, and it's not like I don't know numbers can't be reused. And yet I configured this in a way where a unit could be lost, even lost BECAUSE of the way we set up numbering so that numbers could not be double-assigned and this problem could not occur. That is not an intuitive thing and the configurer would have to read the very small print in the users manual to avoid the problem.

[urapadmin]

NO NO NO. NOTHING WOULD BE LOST! Just to get that disaster out of your mind, even if you take pains not to call it one: It would still not have been one. In fact this would have been the one instance when you would have gotten what you planned to begin with: A Unit 40 and a unit F40. No, we would not have lost anything. Not even created a glitch in your scenario.

But of course I can envision accidents when the exact same context identifier would be produced at the same time by two ipads, e.g. if you think that a feature unit and a survey unit are entirely different things and give them both the same identification method or identification methods that can result in the same identifiers. Easier: Use free input and both type the same identifier in the field. BUT EVEN THEN we do not lose anything! We would end up with two units having the same identifier. But they are still distinct because our synchronization relies on universally unique identifiers in the background. The result would be bad enough but still miles from losing recorded data. I took that part really serious during the design of the system and that is why Luiza makes me jump (and you should, Luiza!) if there seems to be danger that we actually lost something FOR THE FIRST TIME EVER IN 6 YEARS. And we did not.

That being said, I agree that there can be confusion. But for the time being this does not worry me because I do not expect any other director to configure their own identification methods for a while. And should that day come we need more than just a different handling of this one issue. We would need a user interface that guides users through the process.

I will think about the particular issue we have here but I cannot think of an easy solution, right now. Your suggestion won't work.

[lbestock]

This is such a relief. What a great system (that is not hyperbole).

(But Luiza I'm going to have to give you some more (and, ah, different) survey unit numbers round because Sam used 'em all for features. And Oren's only got three before he runs into the same problem, and he was so quick to download that I can't even sneak in there and do it before he gets ahold of it.)

[luizaogs]

Woops was in a meeting. Wow was this not even a Luiza-ism? Miracles do happen, guys. Though sorry about the heart attack, Lutz; I should have emphasized that even if those had been lost they would have been bogus units!

[urapadmin]

to myself: What about using the domain a bit differently? We could define the domain as a combination of the actual domain (if there is one) and a static part. In that case the usual domain/local-id mechanism would be allowed to create redundant local ids. That would also solve a possible request that unit ids have to be unique only within sites.

But: not all numbering methods consider the domain currently. If I am not mistaken, idgen_group does not.

[urapadmin]

I am really not concerned that we lose any of our bogus data here. But if synchronization makes a mistake we are talking about the sacred inner core of this system and every error in there would be systemic and question the fundamental idea behind it, That would be a disaster. So please never get tired do raise the slightest suspicions that something might have gotten out of synchronization than it should have. I am happy to jump in vain over and over again.

[luizaogs]

I hope it is at least good exercise, the jumping.

[urapadmin]

I like identification methods. They remind me of that other book I planned to write: "On ... " Hm. And there I can't remember the term and when I tried to look it up I found that my litwiki does not exist anymore and I have no idea where my backups of my philosophy studies is. Sad.

[luizaogs]

THAT strikes me as a disaster!

[luizaogs]

(Hey we do have a survey unit 48 and a feature F048! It worked perfectly.)

[urapadmin]

what? Where? In the new data? (still looking at your last uploaded version).

[luizaogs]

Yup! I have survey unit 48 and Sam has feature F048. Just saw it after downloading it again.

[urapadmin]

funny. Exactly the case I was exemplifying. Works, indeedish. Well it is still confusing why it seems it can and cannot happen all at the same time, and admittedly not easy to explain let alone defend as the proper solution.

I'll think of something. One of these days.

[urapadmin]

Now that we have these identification methods that allow all kinds of funny numbering strategies for all kinds of projects I thought I had reached a point of peace here. And that's where we run into today's poetic reference, which in fact I could write under more or less every ticket here. These insatiable directors:

Niemals

Wonach du sehnlich ausgeschaut, Es wurde dir beschieden. Du triumphierst und jubelst laut: Jetzt hab ich endlich Frieden!

Ach, Freundchen, rede nicht so wild, Bezähme deine Zunge! Ein jeder Wunsch, wenn er erfüllt, Kriegt augenblicklich Junge.

Wilhelm Busch

I leave the translation to you as an excersise.

[luizaogs]

Aha! Seems indeed quite fitting (and is surprisingly understandable to my largely illiterate German self).

[urapadmin]

written for all the former German grandma's to have something for their stiching (they used to make these kitchen linens to cover things and they had homely, often enough somewhat puritam aphorisms on them). Still good for non-native speakers :o) Busch would not have dreamed to end up with this even on Github.

Am 24.07.2020 um 23:21 schrieb luizaogs - notifications@github.com:

Aha! Seems indeed quite fitting (and is surprisingly understandable to my largely illiterate German self).

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/urapadmin/kiosk/issues/776#issuecomment-663739507, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJIKAKQB6O2RCBRHQJANIUDR5H3NPANCNFSM4PG6OLJA.

[lbestock]

Unsurprisingly all the examples I can find of American ones (we did this, too) are beyond cheesy. This one at least doesn't mention god, which makes it a rarity:

[luizaogs]

Aha that's on the same level of listing things we're thankful for on Thanksgiving. Americans.

I don't think that grandma would've ever expected this to end up on GitHub, either.

[urapadmin]

Hillarious. It resembles "modern" aesthetics in being so pixelated. The ones in our kitchens were not framed just linen used in the kitchen as a normal household good. And less colorful. Just white and blue. But a lot of god on there, too, often.

[urapadmin]

We are so off topic again :o) Github will fold our enterprise one day.

[luizaogs]

Meh. You might get an award for most insane project, however.

[lbestock]

This one is in Emily Dickinson's own hand! All about god (I can't really read it but Harvard says so.)

[luizaogs]

All I see mentioned are children but isn't Harvard always right?

[urapadmin]

this can be closed, right?

[lbestock]

Yes.

Laurel Bestock Associate Professor of Archaeology and Egyptology Director of Graduate Studies, Joukowsky Institute for Archaeology and the Ancient World Brown University

https://blogs.brown.edu/archaeology/fieldwork/uronarti/

On Sun, Jul 26, 2020 at 5:56 AM urapadmin notifications@github.com wrote:

this can be closed, right?

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/urapadmin/kiosk/issues/776#issuecomment-663967683, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALYCFBK7G4JHIZN42ZAUYVDR5P4URANCNFSM4PG6OLJA .