Question

Advanced Search Syntax for Entry ID's Ending in a Specific Number

Search and Retrieval

Updated October 6, 2015

asked on October 5, 2015

I am running a search for any entry that ends with "1" and am pulling back all that end in "1" and all that end in "10" or "100" or "1000" and so forth. Here is the query:

{LF:ID=*1}

It appears to ignore the ending 0's when searching for an entry ID that ends with a 1-9. Additionally, if I run the same search for entries that end in "0" I get no results found.

Is this a known bug or should I be running the query differently to find all entries that have entry ID's that end in a specific number?

0 0

Answer

SELECTED ANSWER

replied on October 5, 2015

This looks like a bug, but why are you searching for ids ending with 1? There might be a better way to do what you want.

0 0

Replies

replied on October 5, 2015

My process still works with this bug as all docs are still found but I'd prefer this function in the way expected. As far as why to use it:

Scenario: You are running a search for all documents in a folder (that all have the exact same metadata) that need to be processed within the same workflow. Your search returns 1000's of documents and you want to speed up how they are processed.
- Option 1: Run a Find Entries on the folder and send them through a For Each Entry activity where they'd be processed one at a time.
- Option 2: Have a Parallel activity with each branch having an advanced search for the same folder but one is pulling back the docs who's entry id end in an even # and the other pulling back the docs who's entry id end in an odd #. This allows me to process in parallel documents that otherwise have no distinguishing characteristics (same name, path, template, & metadata). If need be I could also break this down more and have a branch of the parallel activity for each number 0-9.

Since these are all named the same I could go based on the end of the name, (e.g if it ends with "1)", "2)", ...) and accomplish the same results. But I'm assuming eventually there may be situations with different named documents in these folders so I am trying to find the one constant across all of these, which is entry ID. Please let me know if you have any suggestions for parallel processing 1000's of documents within a single workflow that are stored in the same folder and have the same metadata.

0 0

replied on October 6, 2015

Option 2 is not actually any faster. The searches are processed sequentially for performance considerations. Find Entries, if it's a possible alternative based on your criteria, is faster than Search Repository.

I'd like to suggest option 3: Find Entries followed by For Each that invokes another workflow to process each document. You're still processing each document one by one, but once you hand it over to the sub-workflow, you are taking advantage of the multi-threaded nature of Workflow.

Or depending on load, you might want to consider option 4 for even more parallelism: publish 10 copies of the sub-workflow with separate names and based on the last digit on the entry, invoke the corresponding copy. I wouldn't go this far unless we're talking about millions of entries that need to be processed in a relatively short time and you have a beefy server (both WF and SQL). In this case, I'd also limit the number of results in Find Entries and run the main workflow multiple times.

1 0

replied on October 6, 2015

Option 4 would work but takes a ton of time to build. Option 3 wont work because in this case the For Each Entry activity is actually invoking a workflow that then passes parameters back to the parent. This means that I have to wait for the invoked workflow to complete and thus I am back to processing 1 by 1. I didn't mention that as I wasn't trying to go too far down this path and mainly just wanted to report what I think is a bug in the Advanced Search Syntax. For a situation where there is a need to simultaneously process a batch of documents down multiple paths (with no clear way to break them apart), I really like using the last digit of the entry ID as I seldom need to break the batch up into more than 10 branches.

I really do appreciate the topic of discussion on this as it is always great to hear how everyone handles these common situations we run into.

0 0

You are not allowed to follow up in this post.

Question

Question

Advanced Search Syntax for Entry ID's Ending in a Specific Number

Answer

Replies

Sign in to reply to this post.