CWS GetNodeByName in CS 16.2 - can you ignore case?

Hello,

I've been tasked to update an existing in-house tool that we have that find sub-folders with specific names in multiples root folder in our Content Server 16.2 environnement. The tool uses the CWS api with the GetNodeByName function to do so. One of the update requested to the tool is that it needs to always ignore the case of the searched subfolder name (for example, the tool need find the subfolder whether it's name is "EXAMPLE" or "example" or "eXAmpLE").

After I tested it, it appears that GetNodeByName doesn't have the option to ignore case. I could use ListNodes instead to iterate on each subitem each time, but since this tool needs to process a great number of folder each containing a lot of children, that would seem pretty inefficient to me.

The other option I have is to refactor the tool to use the REST api instead (the node api "where_name" filter seems to ignore case during my tests) but that would take significant time and changing api is a bit out of the scope of the requested changes to the tool.

I was wondering if there was any know way to use GetNodeByName while ignoring case?

Thanks in advance!

Find more posts tagged with

Comments

Appu Nair

@Jean-Christophe Savard if you pass to GetNodeByName something in CWS

Node clue=docManClient.GetNodeByName(ref otAuth, 74143,"example");

what it does is pass the string faithfully as you typed in code CaSeWiSe

Nowhere would it bother to search any subfolders as implemented...

Is your system something customized by others that changed the OT implementation?

If you pass EXAMPLE in Folder 12345 it will find it as well as if you pass example or eXAmpLE

Node clue=docManClient.GetNodeByName(ref otAuth, 74143, "eXAmpLE"); //this returned a valid Node when the object was called 'example'

In my SQLserver system which I put as a Case Insensitive Accent Insensitive I can find that almost like a wildcard. I guess what you are running into is perhaps a system that is case-sensitive.

you could also create a simple LR which has the SQL select * from DTree where parentid=<passed in> and Name like <"example"> // and appropriately uppering or lowering the call or even use DTreeAncestors or DBrowseAncestors to work around.

GetNodeInContainers,GetNodeBypath all seem to be useful as well.

Just my $0.02

#AOTDEV2D

Jean-Christophe Savard

Hi @Appu Nair ,

Thanks for the answer. I double-checked on my side since your behavior of GetNodeByName seems different than ours. On my side I do need to input the exact same case for GetNodeByName to find the node. Ex:

We can see that the searched for node in the 38415497 root folder is in reality named "ALL CAPS" here (see the "realName" value), but searching "all caps" or "All CapS" is not finding it. Only the exact case is returning a Node object instead of null;

Maybe it's caused by a Content Server configuration or database setting specific to our environment, like you proposed, although I'm not thinking of anything right off the top of my head. I'll check on my side if I can find something that would explain this difference in behavior from your own tests.

Appu Nair

To me it looks like in your system under the same folder aka Parentid you are able to create a folder called Upper , UPPER or uPper in my system I can only create one of the objects . If that is the case then chances are you are on a CS Oracle I have worked in those systems although most SQL server Livelink’s are always CI .

There might be ways to change it’s behavior but the real thing is does your system need to be CS ?
#AOTDEV2D

Jean-Christophe Savard

Hello Appu,

You are actually right! I just tried it and I can indeed create items with the same name but varying case in the same folder (we are indeed using an Oracle database). I'm a bit surprised, I'm pretty sure we could not do duplicate name with differing case in the same folder in the past, although I didn't actually try to do this in a good while. I wonder if something changed on our side in a database or CS config somewhere to enable this that I missed. I'll check with my CS server and my database administrators to see if I can pinpoint the reason.

Well since it's possible to do duplicate names in the same root in our environment, I guess the GetNodeByName is working as intended then, so I'll check for alternate solutions tp modify our tool.

Thanks for the help!