Here are answers to your questions --- let me know if this helps.
a. Version object requests do indeed create new object IDs for the newly created objects.
b. The Atmos object interface automatically creates the object ID as you have seen. If you need to name your own objects then you may consider using the namespace interface, but you'll need to manage the namespace of objects to prevent from storing too many objects in a single directory.
c. When objects are deleted they are immediately de-referenced from the developer point of view, but will be actually deleted a short time later depending on system activity, etc. This should not impact your use of Atmos from an API developer standpoint.
d. Can you clarify this question? If you're asking about getting a list of all used object IDs globally this is not possible. You can get all object IDs for a given metadata key or all objects for a given directory path.
e. It is not possible to reserve object IDs unfortunately.
f. There is not a search engine necessarily for Atmos. There are some fairly rudimentary means of "searching" where by a developer can search by metadata key or directory. Can you describe your use case and requirements so that we can better understand your needs?
To clarify what I'm looking for is to help our development-team to understand atmos API. So all questions above are the output of our first discussions.
a) The use case of the versioning is in daily business they will change mostly metadata but from time to time they must change the object-content. So if it's not possible to change object/metadata without changing OID in their backend-db they will have much work to do.
b) how many namespace-object are allowed in atmos? So the only way to solve this is to have a user-metadata field which includes their own created UUID?
c) Ok understand
d) Yeah, this also confused me a bit - i will ask for more details. But nevertheless thank you for your answer
rbala1
222 Posts
0
April 30th, 2012 06:00
Hello,
Here are answers to your questions --- let me know if this helps.
a. Version object requests do indeed create new object IDs for the newly created objects.
b. The Atmos object interface automatically creates the object ID as you have seen. If you need to name your own objects then you may consider using the namespace interface, but you'll need to manage the namespace of objects to prevent from storing too many objects in a single directory.
c. When objects are deleted they are immediately de-referenced from the developer point of view, but will be actually deleted a short time later depending on system activity, etc. This should not impact your use of Atmos from an API developer standpoint.
d. Can you clarify this question? If you're asking about getting a list of all used object IDs globally this is not possible. You can get all object IDs for a given metadata key or all objects for a given directory path.
e. It is not possible to reserve object IDs unfortunately.
f. There is not a search engine necessarily for Atmos. There are some fairly rudimentary means of "searching" where by a developer can search by metadata key or directory. Can you describe your use case and requirements so that we can better understand your needs?
Raj
michalefty
2 Posts
0
April 30th, 2012 07:00
Hello Raj,
thank you for your helpful answers.
To clarify what I'm looking for is to help our development-team to understand atmos API. So all questions above are the output of our first discussions.
a) The use case of the versioning is in daily business they will change mostly metadata but from time to time they must change the object-content. So if it's not possible to change object/metadata without changing OID in their backend-db they will have much work to do.
b) how many namespace-object are allowed in atmos? So the only way to solve this is to have a user-metadata field which includes their own created UUID?
c) Ok understand
d) Yeah, this also confused me a bit - i will ask for more details. But nevertheless thank you for your answer
e) Ok if this is by design - no worries
f) Ok thank you
Thanks for your help
Michael