nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Fun with Search Constraints

System

I am trying to put a search query together that will, in a nutshell, find all the expired files that are not in 2 specific file paths. Should be easy with the wizzbang set of constraints that IW provides to accomplish such an easy task, but this is Interwoven after all, so it will not be easy.

Here are the basic requirements. We have an existing search query (built with the Java CSSDK) that determine if a file is expired based on its 'Expired Date" metadata. This works fine. Due to some new functionality, I now need to make sure the expiration process does not expire any files in these relative paths:

this/relative/path*
this/other/relative/path*

Keep in mind there are about a dozen other folders within the root "this" folder where we do want to expire files. I designed the query as this:

[HTML]

[/HTML]

What this ultimately does is expire everything in all relative paths EXCEPT "this*". Rather than only exclude the two specific paths I indicated, it is excluding all paths that begin with "this". Not exactly what I expected.

I suspect the NOT constraint may not work the way I expect it would with a path. I have opened a support case for this, but so far crickets.

By the way, the query turned into this search predicate, which appears correct to me:

[HTML]templatedata/service/schedule*templatedata/contest/contest_entry*[/HTML]

Has anyone used search constraints heavily and understand how I can accomplish what I want?

Find more posts tagged with

Comments

Migrateduser

Those funky characters in the first block are double quotes.

nipper

I assume this is only in TS and not runtime. Do you have LSDS/LSCS ?

Untitled.png

Migrateduser

Yes in TeamSite - the actual code is in an externaltask in the workflow. We do not have any flavor of LS.

I have been using the CLT iwsrchquery to play around with it and try different permutations of the constraints. I took out the expiration part completely and am just trying to find a search that will return me all the files not in a particular path, but no luck so far.

I think NOT just doesn't work properly with a filepath.

An OR wrapped around two filepaths does indeed do the right thing.

Adam Stoller

I am trying to put a search query together that will, in a nutshell, find all the expired files that are not in 2 specific file paths. Should be easy with the wizzbang set of constraints that IW provides to accomplish such an easy task, but this is Interwoven after all, so it will not be easy.

Here are the basic requirements. We have an existing search query (built with the Java CSSDK) that determine if a file is expired based on its 'Expired Date" metadata. This works fine. Due to some new functionality, I now need to make sure the expiration process does not expire any files in these relative paths:

this/relative/path*
this/other/relative/path*

Keep in mind there are about a dozen other folders within the root "this" folder where we do want to expire files. I designed the query as this:
[HTML]

[/HTML]

Heh - you remembered to obfuscate the information in the first instance but not within the code :-)

Have you tried:

<AND>
  <current Expiration Date Constraints>
<OR>
    <NOT>
      <path="this/relative/path*"/>
      <path="this/other/relative/path*"/>
    </NOT>
</OR>
</AND>

Note - I wasn't sure if the XML you presented was symbolic or real - but I made the 'path' elements empty elements syntactically correct.
Also - are you sure it's just "

" and not "

" for the path spec?

Migrateduser

Thanks - now I need to go look up 'obfuscate'. Smiley Surprised

Anyhoo...I think I tried that permutation but I will try again. I tried a few. And the XML was symbolic, but yours looks better.

According to the stellar (not really) documentation, they simply have 2 wildcard characters (?=a single char, *=0 to many chars) and not a typical regex format. They have examples and they only use the *, so I think that's correct. It seems to work when you just OR the two paths. I'll give that a shot and post the results.

Migrateduser

OK your idea I think may work. I've been able to test it somewhat using the CLT and a query string, but I am looking at the CSSDK and am not sure how to build that query using the constraint classes. The CSNOTConstraint constructor takes a single CSConstraint as an input parameter. There is no way that I can see to pass it an array of CSConstraints. The CSAndConstraint and CSOrConstraint constructors both take an array of CSConstraints.

Bottom line - I would love to implement this in my Java code and try it but I don't think it's possible due to the limitation in the CSSDK, which I think could be a bug in the CSSDK.

Migrateduser

Never mind - upon further review, this query does not work either.

Adam Stoller

Never mind - upon further review, this query does not work either.

Okay - then try a slight variant:[html]

[/html]Though on reflection, I think this would not do what you want either, and I'd end up going back to your original phrasing.

Dare I suggest that you open a case with Autonomy Support regarding this?

Migrateduser

I opened a case before I started this thread. They started looking at it yesterday. Nothing yet. They claim that NOT should work properly with paths, but I will not be convinced until they show me a permutation of this logic that works. Anything I've tried that combines a NOT with a path/wildcard does not return what you'd expect. I'll post the results of the support case. Thanks a bunch for your help. So frustrating.

Migrateduser

My support case on this is finally making some progress. They have confirmed that it is not doing the right thing. When I use the logic:

[HTML][/HTML]

rather than exclude results with any path matching this/relative/path*, it returns results that excludes:

this OR relative OR path*

Ooops. So the workaround so far is for me to use only path* in my query but this will not be sufficient since path is likely too generic.

Not sure what the ultimate solution will be but I'm hoping it's a bug they can patch.

Adam Stoller

My support case on this is finally making some progress. They have confirmed that it is not doing the right thing. When I use the logic:

[HTML][/HTML]

rather than exclude results with any path matching this/relative/path*, it returns results that excludes:

this OR relative OR path*

Ooops. So the workaround so far is for me to use only path* in my query but this will not be sufficient since path is likely too generic.

Not sure what the ultimate solution will be but I'm hoping it's a bug they can patch.

On a whim - try:

<NOT><path="this\/relative\/path*"/></NOT>

The thought process being, based on what you just stated, that perhaps the regex is interpreting the path separator as a delimiter and that maybe if you escape it, it will work.

If nothing else, you'll rule it out as a solution.

Migrateduser

Tried it and it behaved the same. I am at least happy that they reproduced the problem. One would think that a patch might be coming, but I'm a dreamer...

nipper

It won't be exactly what you need, but it may get you close (and it also may filter out something you want), but how about:

[php]

[/php]

It will filter all 3, but not in the order you specify

Migrateduser

It won't be exactly what you need, but it may get you close (and it also may filter out something you want)

I get it, but close won't be enough to get me to production with this. I need it to work precisely, which I know is asking a lot of Interwoven. This query is for an expiration of content process and if it misses anything at all, that could cause legal issues because our content has lots of time sensitive pricing and advertising. I've at least got them to admit it's a problem.

Migrateduser

I finally got a solution to this problem. The string representing the path needed to be changed when using the NOT constraint with a path. From the docs, it appears that the syntax should be:

[HTML][/HTML]

[left]

[/left]

However this does not work, as I've shown previously. What it needs to be is this (notice the training slash instead of the asterisk):

[HTML][/HTML]

[left]

[/left]

For whatever reason, this works and returns the resultset I expect.

Unfortunately the other syntax must be used when you do not use the NOT constraint.

Migrateduser

They lied. I lied. It still doesn't work. The results are the same as in my initial post. This logic is producing results of everything that is expired EXCEPT in the root/* path structure of the paths in the constraints. This has been very frustrating - especially because IW can't seem to duplicate this. But they have been testing on Windows and not Linux - not that it should matter, but none of this makes sense anyway.

We have another separate case where some files in the same path that have expiration date metadata in the past are expiring properly (meaning Search finds them when we search for all files that have expiration date in the past), and some files it does not find. In the same folder.

Maddening.

Adam Stoller

Given how funky Search is, you're probably better off pushing the information to your own DB and then querying that instead - either that or writing your own code to traverse the directory structure and check each and every file it finds that conforms to your path restrictions ... but the DB would be far more efficient....

Yes - Search should work - but given the issues, how long do you want to wait for Autonomy to actually figure out what the problem is - and fix it - versus getting what you need to do done....

Migrateduser

The short answer is "as long as it takes". It is just not feasible for us to develop a DB solution where we publish all of our content to a DB - setting this up and developing the code around it would be a fairly major project. We just don't have the resources to do that - and my management would **** a brick if we suggested that we "roll our own" search solution when they pay a bazillion dollars every year for supporting this **** of a product.

I get what you're saying but we just don't have the manpower to do it. There are a lot of projects in the pipeline to support the massive changes happening at my company right now. No way this would fly.

Adam Stoller

...No way this would fly.

Pun intended?

I understand - and in general, I agree - if one is paying [a significant amount of ] money for a product, one expects the product to function properly.

Good luck working your way through HP::Autonomy::Interwoven Support / Engineering to get this fixed.