Hello,
I couldn’t find any documentation on on the persistence of internal ids (the *HEX type id) that are returned by APIs for referencing objects.
Is it safe to assume they will not change for a given object unless the object is deleted/recreated? If I create an object by the API, is it safe to store/cache the *ID elsewhere and use it to reference the object long term?
thanks,
L
Yes, the * .id attributes are safe for persistence through reboot/upgrade/etc. If item is removed and recreated, previous * .id aren’t not generally re-used - so reference to the .id may have to be updated if you remove/add a new item. But a “set” on existing item will keep same * .id.
You can always confirm the .id using “/some/command print show-ids” which will cause print to show the persistent * .id.
Is one idiocy use ids or “number on print”.
You must everytime obtain again the id for the object you want work on (is valid till the end of the session), and when is possible, simply use the name of the object instead of it’s id.
If you are planning always to restore config from backup, ids will not change and you are safe there, but on import not. You will then need to be careful who has access to admin so that someone (or you by accident) cannot for eg. delete and recreate existing rule which will create new object with different id for same configuration, this means ROS configuration sections which objects ids are persisted on external system must be explicitly managed by that system to be safe.
Generally persisting ids on externals system isn’t good practice, since referenced id may change in some cases and you have trouble then, same like for eg. with relational databases, record id is meant to be used for internal referencing, that’s why you can run queries on databases by some attribute(s) condition and in ROS you have filter commands.
My goal is to insert blocks of configuration into an already manually configured system. Such blocks are like firewall/nat rules/lists, new interfaces, routes etc.
I need to be able to change, remove these configuration snippets when external conditions change without disrupting the operation. And remove them altogether and return the router configuration to pristine state.
I do not mind to have a procedure to refresh it all by wiping all customizations and reprovision them all, but it has to be an emergency operation, not the day-to-day way to manage change.
Only ways to manage that, seems to be using the comments to store data, and storing the *id externally for the applied changes.
The difference with rdbms is that you can have arbitrary identifiers in records, while routeros API only have comments to store arbitrary data, and, correct me if wrong, filters don’t allow for partial searches, just exact match.
You can also generate random uuid as external system id per configuration rule and put into rule comment. It will be more safe and you can always filter by comment to find it.
That exactly how I am doing it now, works, but update and delete operations typically take two requests as i need to get the *id first. Was considering caching *ids externally, so i could operate on those directly, as long as the device state appears to be coherent. Can always fall back to “safe” mode and use uuids first for each operation.
I you have fall back to uuid then it should be safe, then you need to be careful when you need to restore configuration on device and do it with backup, because on import some different rule can get same id which is related to another on external system, unless you have some process to trigger force refresh all cached ids by finding all rules by uuid in comment when import on device is applied.