We store uploaded files in Documentum and in the event someone uploads files with the same name, we would like to be able to retrieve the correct file using the Rest API.
We store metadata (filename, etc.) in the database as part of a queue of work. So a user will go in and pick the next item in the queue (in this case look at the uploaded file). Currently we look up using the filename and return the first file which is not ideal.
I know you get the Document back (including object id) upon upload, and I was thinking about storing that along with the other metadata, and we can compare that, but I stumbled across an article suggesting this was a bad idea.
I'm new to Documentum, so how do others manage this?
The referenced article is correct. Using of r_object_id for external references is not good idea especially because of the possible future migration. Because r_object_id contains the docbase ID and when you migrate into a new docbase then all documents will have different r_object_id.
You can solve it by adding of a custom attribute to the document type, where you can store copy of the r_object_id value (can be implemented by TBO) or generate your own ID (it can be also implemented by TBO or DB sequence), when the attribute is not filled in yet. Then you can use this value as a unique reference to that uploaded document.
And when you migrate into another docbase in the future r_object_id will change but value of that custom attribute will still remain the same.
Related
This is my first time using Ektron and i'm trying to implement Json-LD schema scripts for each page. I have 68 scripts that I need to implement that are unique for each page.
I thought I would be able to implement these scripts through meta data, but now i'm unsure. Each script is over 1000 characters, the html and meta tag types only allow 500 characters, so i'm assuming i'm in the wrong place. If anyone could shed some light it would be much appreciated.
Ektron's metadata isn't intended for large chunks of data / content. So, yes, you will find limits there.
Here are two things you might try as workarounds.
Most direct:
Use the Ektron Library. Go to the Library tab and click on the Root node and view Properties. Add an extension to allow you to upload your JSON-LD as a file. Use metadata on the content item to reference the uploaded file. Combine the two upon output.
If you want the JSON-LD to be editable within the CMS...
Gaming the platform a bit
Create a new SmartForm definition and include in it a single plain-text, multi-line field (not Rich text). This should hold your JSON-LD. Set up a folder and, if your version supports it (you didn't specify CMS version, so I will assume relatively recent), set the folder to be non-searchable so these things don't come up in site search results. Add a restriction to the folder to only allow the Smart Form definition you just created. Create your JSON-LD there using the plain-text field. You should be able to store up to 1MB.
Same as above, add your JSON-LD as text then use a reference to this item from the content you want to use it.
The metadata in this case (and possibly the library one, though I'd have to test and I don't have an Ektron environment for development anymore) will give you the Content ID for the object holding your JSON-LD. You'll have to make another API call but will give you the solution you appear to want from above.
I want to fetch the events related to my dropbox like I can see here , means I want to get when a particular file is added, changed, moved, deleted or renamed and by which user.
I have looked into the Webhooks docs. The webhook docs states the the response it sends to the callback url contails the userids, with which I can update the directory listing based on the webhook response for the user by calling the /delta.
But with it I cannot tell if there is an operation made for a file like a particular file has been renamed or deleted as since if I rename a file fro abc to xyz. If I get a response then I will look for the changes related to the file xyz which I will not find in my existing database so logically I will be making the events as deleted abc and added xyz, where as the reality is renamed abc to xyz.
It will be really grateful if you can help me regarding this.
There's no real way to detect a rename (versus a delete and an add) via the Dropbox API. You can use heuristics (like whether the new file has the same contents as the old file and was created around the same time as the old file was deleted), but those are just going to be guesses with varying levels of accuracy.
Also, there's currently no way via the API to see which user modified a file in a shared folder.
UPDATE: The Core API now includes (in beta) the ability to see who last modified a file in a shared folder. See https://www.dropbox.com/developers/blog/101/new-in-beta-shared-folder-metadata.
A file rename is reported as DeletedMetadata followed by a FileMetadata for the file.
What is annoying is that DeletedMetadata do not contain the file .id attribute, only .name and .path, while FileMetadata include all attributes (.id same as before any deletions/renames, updated .name and .path).
So you should have a local mapping connecting names/paths and IDs in order to know which file got deleted (when only DeletedMetadata is received) or renamed (when both DeletedMetadata and FileMetadata are received).
I am using the REST API for OneDrive. I have a name of a file in the users storage. I want to obtain the properties for this file. According the documentation file's properties can be retrieved
if you have the file ID.(http://msdn.microsoft.com/en-us/library/dn659731.aspx) So I need the file ID and the only way I see to obtain it is to search the whole storage which is really unnecessary.
Is there a way to find properties of a file(with a known name) with a single request to the service?
Ideally the API would support access by path which would do what you require (assuming you have the full path and not just the name). Unfortunately, to my knowledge that isn't supported.
There is a heavy handed approach that may work for you though - you can use the search capabilities of the API to find files with the name you specify:
GET /[userid]/skydrive/search?q=MyVideo.mp4
The documentation is available at the link below:
http://msdn.microsoft.com/en-us/library/dn631847.aspx
I have the need to add a licence field to the APIs published by the API manager.
It does not seems to be any extension point beyond the api.rxt file in the resource folder.
If I modify the file and run the application the carbon app correctly show the added field, but nor the publishe nor the store are able to get the field and there is no way to get it also with REST APIs since it calls a method of a class that (in later versions) outputted fields positionally.
Is it possible to add the field, without running the risk of crashing the API Manager?
Which is the correct way?
Thanks
This change cannot be done without modifying the code. When an API is created from the Publisher app, it gets stored in the registry. The api.txt you modified, only defines the structure of this stored artifact. It may add a new field to the artifact, but to correctly populate that field, you need to modify several methods in APIProviderHostObject and APIProviderImpl + several Jaggery scripts.
I became interested in CouchDB recently and wanted to try and form a small application around it.
The way how I invition my system currently is that requests come providing two things, a id, a API Key and a format. The ID is the _id of a document in the database, the API Key is a _id of another document that has a property of {"valid" : true/false}, and the format is the format they want back. If the API Key is valid, the system would generate the show page for the id given, in the format requested. Otherwise it would return a 403 stats code.
Unfortunately I can't find a way to pull up another document from a show page. I am just beginning CouchDB, so maybe there is something simple here I'm missing.
With a _show function, there are three parts involved:
The design document
The show function inside the design document
The additional document to be shown
For the URL format /db/_design/ddoc/_show/my_show_func/otherdoc:
The design document is _design/ddoc
The show function is shows.my_show_func within that design document
The document to be shown has an _id of otherdoc
Those are the only two documents involved. The only way I can think to do what you describe is have a design doc per API key. The user would query /db/_design/API_KEY/_show/other_doc_id. CouchDB is relaxed. There is nothing wrong with thousands of design docs with identical or similar _show functions. You coul use the HTTP COPY method to clone a base design doc to a new API key as needed. Then you could revoke an API key by deleting the design doc. However that is obviously a unique approach, worth a second thought.
A final consideration is (with the default CouchDB, no reverse proxies, mod_security, etc.) if a user can read one document, they can read the entire database (e.g. from the _all_docs query.) Therefore show functions are a convenience for the software but not a security gateway.