Querying in Livelink V8 vs Livelink V7.3

After upgrading from V7.3 to V8, I noticed that one of the APIs, LL_ExecuteQuery, had been removed, and was told that it had been superceded by another set of APIs in the search. The new APIs, which include LL_ApplyQuery, allow the developer to conduct a search of items that have been indexed by the system.I believe some functionality has been lost in the process. I would like an API that lets me do SQL type WHERE clause to search for an item based on item information as well as its category and attribute information using the underlining database (not the search index). Currently, it takes time for an item to be indexed (at least a minute after LL_CreateObject), so the information is not immediately available to a query. Also, the system administrator must manually modify slices to include additional attribute information, whereas with LL_ExecuteQuery, the developer could search against any existing category or attribute. The syntax for the search is very different than what was available for the where clause, and I believe some types of queries can not be formulated using the syntax (exact matches, wild card search, dynamic metadata search, etc.). Finally, there is a performance loss using the search engine rather than the database to perform queries that do not require the full text search engine for simple queries.Is it possible (1) to have a generic LAPI function that allows me to formulate my own SQL statement, similar to CAPI in the builder, that uses OpenTexts database connection, so that I can have all the flexibility that I will need, (2) expose my own functions from builder to LAPI and implement this type of functionality as well as others myself, and/or (3) bring back the functionality of LL_ExecuteQuery? My first preference is the first option but the second option is also appealing for other things I may want to do.BTW, LL_ListObjects does have some of the features that I am looking for (SQL Where clause, fast performance) but it only lets me find direct children and does not let me search on attributes and categories without creating special views.I do not want to have to create a separate database connection in my program using ODBC or OCI or dbLibrary, etc, just to query ithis nformation from the system.Thank you.

Find more posts tagged with

Comments

Ryan_Sweet_(rsweet_(Delete)_593809)

I find it interesting that you think the LL_ApplyQuery has removed functionality from LAPI. I think that the LL_ApplyQuery has increased the functionality of searching in LAPI. I believe that the query syntax is as strong, the indexing time is irrelevant, exposing attributes is an advantage and the results return faster than LL_ExecuteQuery.I can understand the need for the SQL syntax. We are all comfortable with SQL and have no problems assembling the correct query quickly. However, I can assure you that the new query syntax can retrieve any information that a SQL where clause can.Is the indexing time a great concern for LL_ApplyQuery? If an object is created within Livelink, is there a great need to query against it immediately? Isn't the information in that object already known to you? I can't think of an example where I would need to query against an object I have created for information.Manually exposing attributes is not a loss of functionality for LAPI. Once the attribute is created it can be exposed immediately. Of course, this is an extra step in the attribute creation process. However, I believe it addresses some security concerns we have received on the support desk. This gives the Livelink administrator more reign on the information presented to end-users.In my testing, LL_ApplyQuery is faster than LL_ExecuteQuery, no matter the complexity of the query. Of course, LL_ApplyQuery is much faster on complex queries than LL_ExecuteQuery. I have never had LL_ExecuteQuery return results faster than LL_ApplyQuery. I am interested if you are finding different results. Is your search server on a remote machine across a slow network? :)Given the strong query syntax, more reign on information presented to end-users and faster performance I don't see how there is a loss of functionality in LAPI? Please, let me know what point I am missing.Ryan

Mike_Oliver_(ollie_(Delete)_137504)

Ryan, is quite right that the new query mechanism is usually faster, and when doing simple attribute searches is every bit as powerful. I would also say that we need the exposure of CAPI.Exec through LAPI for any number of reasons, but mostly because that will make integration of legacy applications easier and will facilitate use of stored procedures and more complex searches than could ever be accomplished with the full text search even with regions.Lets say that a legacy application has a stored procedure that returns a list of values based on some input parameters, and we want to limit our search to those documents that contain any of those values in an attribute. Without CAPI.Exec we cannot do this query within LAPI, with CAPI.Exec we could execute the stored procedure, get the results and then feed the ApplyQuery and merge with full text and region search and get the best of both worlds. I have always thought the omission of CAPI.Exec in LAPI was a mistake.