You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@manifoldcf.apache.org by "Karl Wright (JIRA)" <ji...@apache.org> on 2012/12/06 09:18:58 UTC
[jira] [Comment Edited] (CONNECTORS-578) Livelink connector needs
access to general metadata
[ https://issues.apache.org/jira/browse/CONNECTORS-578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13511223#comment-13511223 ]
Karl Wright edited comment on CONNECTORS-578 at 12/6/12 8:17 AM:
-----------------------------------------------------------------
How consistent is the list of attributes from Livelink instance to Livelink instance? In other words, there is undoubtably a set of ones that cannot be changed, and there may be a set that can be added as a customization. If the set is constant, that would save a lot of work; we could make a point of simply always including the ones you want, with no UI changes at all.
was (Author: kwright@metacarta.com):
How consistent is the list of attributes? In other words, there is undoubtably a set of ones that cannot be changed, and there may be a set that can be added as a customization. If the set is constant, that would save a lot of work; we could make a point of simply always including the ones you want, with no UI changes at all.
> 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
>
>
> 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