missing function

[shengb]

1. Need to show PV connection status at taking snapshot (not all PVs can be connected always);
2. Need to search snapshot according the giving time range;
3. Need to search according the snapshot id;
4. Need to select PV not to restore;
5. The year of timestamp for each PV is missing.

[jbobnar]

1. If PV is not connected, it is red.
2. There is a search button in the browser view toolbar, which allows you to search by comment, user, tag, start and end date.
3. I'll add this the the same search dialog
4. The first column in the table is a checkbox, which does exactly that.
5. If you open a snapshot, you see the year of the snapshot in the Timestamp field at the top. Repeating this year in every single row would be noise and waste or real estate, since it is the same for every PV (unless you have a snapshot from the 1st January, but then the month is already different).

[berryma4]

I'm not sure about exposing ids. In git this could be the repo/sha1, but I'm not sure in masar? Guobao, is it a uid, or just an id (ie. what if there are multiple masar services, is the id unique across instances)?

[shengb]

1. A PV has 2 connection status, the current one, and the one when the snapshot was taken. The red shows its current status, but the status at taking snapshot is missing.
2. Where to find the search button in the browser view toolbar?
3. Thanks
4. Thanks
5. The year shown in the Timestamp field was when the snapshot was taken. The timestamp for PV is the time when the PV was process. If a PV is not processed, its year would be 1989. What's about the case if a PV is not processed during past year (I know it is almost impossible, but might happen to an operational machine)?

@berryma4 For historical reason, MASAR use just an id. The ID is not unique if there are multiple services unless they are using the same database. The use case at NSLS II was that all physicists always talk about for example "Lattice 1234", which means MASAR snapshot dataset 1234. It is even in the official report.

[berryma4]

I hate to repeat the same problem I have with olog. Can we make the ids unique over services somehow? On Feb 17, 2016 8:51 AM, "Guobao Shen" notifications@github.com wrote:

1. A PV has 2 connection status, the current one, and the one when the snapshot was taken. The red shows its current status, but the status at taking snapshot is missing.
2. Where to find the search button in the browser view toolbar?
3. Thanks
4. Thanks
5. The year shown in the Timestamp field was when the snapshot was taken. The timestamp for PV is the time when the PV was process. If a PV is not processed, its year would be 1989. What's about the case if a PV is not processed during past year (I know it is almost impossible, but might happen to an operational machine)?

@berryma4 https://github.com/berryma4 For historical reason, MASAR use just an id. The ID is not unique if there are multiple services unless they are using the same database. The use case at NSLS II was that all physicists always talk about for example "Lattice 1234", which means MASAR snapshot dataset 1234. It is even in the official report.

— Reply to this email directly or view it on GitHub https://github.com/frib-high-level-controls/save-set-restore/issues/14#issuecomment-185211896 .

[shengb]

Yes, we can discuss how to handle the ID properly. The use case I mentioned above was not my idea. The physicists naturally picked up the ID because it is simple and easy to mention. It took me a while to realize the "Lattice 1234" means masar snapshot 1234.

[jbobnar]

1. Sorry, my mistake. It was not yet pushed to the repository.
2. see this screenshot
3. Unprocessed PV will have UDF INVALID alarm status. That is more reliable than the timestamp. Anyways, I'll add the year.

I'll also add the search by ID, but one will need to know the ID from somewhere... I need to display it somewhere.

You may also want to update the python client. Even though search by ID is supported, it's not mentioned in the comments.

[shengb]

1. Thanks.
2. Thanks. It might be better to find it more easily, but it works.
3. UDF alarm is different concept. It is another issue anyway.

In MASAR PyQt UI, I displayed the ID of each snapshot. You might want to do the same thing.

For the Python client, appreciated. Yes, I did forget to update the comments. Thanks.

[berryma4]

I would rather people use the tags instead of ids. I found with olog exposing your internal database id isn't always a good idea.

On Wed, Feb 17, 2016 at 9:04 AM, Guobao Shen notifications@github.com wrote:

Yes, we can discuss how to handle the ID properly. The use case I mentioned above was not my idea. The physicists naturally picked up the ID because it is simple and easy to mention. It took me a while to realize the "Lattice 1234" means masar snapshot 1234.

— Reply to this email directly or view it on GitHub https://github.com/frib-high-level-controls/save-set-restore/issues/14#issuecomment-185220049 .

[shengb]

@berryma4 tag would be an interesting idea. For save set, we need to tag every snapshot data set, which is same with tag then. Olog could be a different use case.

[berryma4]

I'm saying it is a bad idea to expose, use ids in the save restore gui, and that we shouldn't do it.

On Wed, Feb 17, 2016 at 9:51 AM, Guobao Shen notifications@github.com wrote:

@berryma4 https://github.com/berryma4 tag would be an interesting idea. For save set, we need to tag every snapshot data set, which is same with tag then. Olog could be a different use case.

— Reply to this email directly or view it on GitHub https://github.com/frib-high-level-controls/save-set-restore/issues/14#issuecomment-185237188 .

[berryma4]

I guess I'll bite at the last comment. Why would you need to tag every snapshot?

[berryma4]

Let's talk this over in our next group meeting. I would like to hear Vasu, Dong, and Dylan's thoughts.

[shengb]

Good. I want to narrow down the topic to the use case of save set.