[
https://issues.apache.org/jira/browse/CONNECTORS-578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13531151#comment-13531151
]
Karl Wright commented on CONNECTORS-578:
----------------------------------------
Exception has been fixed in branch.
> Livelink connector needs access to general metadata
> ---------------------------------------------------
>
> Key: CONNECTORS-578
> URL: https://issues.apache.org/jira/browse/CONNECTORS-578
> Project: ManifoldCF
> Issue Type: New Feature
> Components: LiveLink connector
> Affects Versions: ManifoldCF 1.1
> Reporter: Karl Wright
> Assignee: Karl Wright
> Fix For: ManifoldCF 1.1
>
> Attachments: procmon.xlsx, stacktrace-startup.txt, stacktrace.txt
>
>
> General metadata access requested for the livelink connector.
> >>>>>>
> All you have to do is call GetObjectInfo with the volumeID (use zero), the
> docID, and a LLVALUE objectInfo (which is just for the returned data; it's
> one of those god awful OpenText rec arrays IIRC)
> On second thought: let me verify this with a code example; but I'm 90% sure
> this should work.
>
> GetObjectInfo should return (in objectInfo) all the data in dtree but I only
> need a subset of that.
> UI display name -> prefix + dtree name
> Name -> ot_name
> Description -> ot_dcomment
> Owner -> ot_userid
> Creation Date -> ot_createdate
> Creator -> ot_createdby
> Modified -> ot_modifydate
> Modified By -> ot_modifiedby
>
> For example, to get the dcomment out of the LLValue
> You would have to do this:
> LLValue elem = ( new LLValue() ).setAssocNotSet();
> String dcomment = elem.toString(“DCOMMENT”);
>
> And that’s how you extract the data out of the opentext structure. It’s kinda
> crappy, you have to know the OT db schema in advance.
>
> Now since owner and creator are sometimes different you would have to make at
> most 2 additional calls to GetObjectInfo to find out the OpenText user name
> (because all you’ll have is a number). So I would check to see if the owner
> and the creator are the same then I only have to make one call.
>
> Listing the general attributes: I would suggest prefixing them with ot_ (for
> OpenText) so the values don't interfere with the general data on the document
> itself. Attached is a picture of the general tab in OpenText. The data itself
> resides in the dtree table.
> And just append it to the array or map that the LivelinkConnector.java
> returns.
> IIRC, you can insert the code around line 1055-1160 after you get the cats
> and atts.
>
> Attached is the GetObjectInfo description from the documentation:
> GetObjectInfo
>
> This function returns an Assoc value object containing information about the
> specified object.
>
> C++ Function Prototype
>
> LLSTATUS LL_GetObjectInfo(
> LLSESSION session,
> LLLONG volumeID,
> LLLONG objectID,
> LLVALUE objectInfo );
>
> Java/.NET Method Declaration
>
> public int GetObjectInfo(
> int volumeID,
> int objectID,
> LLValue objectInfo )
> Input Parameters
> session the session handle as returned by the SessionAllocEx
> function
> volumeID the volume ID of the object. Specify 0 to identify the
> object using only the objectID value.
> objectID the object ID of the object
>
> Output Parameters
> objectInfo a value object of type Assoc, initialized using the
> Value API, containing the attributes for the new object. For more
> information, see ObjectInfo Attributes.
>
> Remarks
>
> For Livelink servers using complex attributes, the category field of the
> objectInfo Assoc is undefined. This function does not retrieve attribute
> definitions.
>
> Any LLVALUE initialized using the Value API can be passed as the objectInfo
> output parameter. GetObjectInfo assigns the appropriate type and value to it.
>
> This function can be performed on any type of object.
>
> <<<<<<
> Followup questions/answers:
> >>>>>>
> To make sure I understand this:
> (1) There is no way to determine through LAPI the names of all
> available general attributes without having a specific item’s
> ObjectInfo object except by describing the dtree table – via something
> like JDBC? (If this is in fact true then I’d prefer to just allow the
> user to enter names of the columns by hand.)
> (2) The general attribute info is found, for any specific object, in
> its associated ObjectInfo structure, and can be retrieved by name.
> (3) SOME general attribute data will require additional processing
> (e.g. lookup of the actual user name given the user id).
> Please correct me if I'm incorrect in any way.
> Is there any different kind of additional processing you can envision?
> Or is lookup of a user name pretty much it?
> <<<<<<
> >>>>>>
> (1) Correct. You could also cheat and just look at the returned LLValue in
> the debugger and see all the dtree column values.
> (2) Correct.
> (3) Correct. Name should be sufficient for the user (it will be the OT
> username)
> <<<<<<
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
