Arguments to pass to DzAssetMgr::searchDB
I have been trying to figure out the form of the arguments to pass to DzAssetMgr::searchDB, but I have yet to find any combination that gives me any assets in the search container that is returned. Time to ask for help!
I am interested in this signature of the method:
DzAssetMgr::searchDB (const QString & str,
const QStringList & categories,
const QStringList & compatibilityBases,
const QStringList & contentTypes,
DzSearchDBThread * thread = NULL,
QObject * finishObj = NULL,
QObject * progress = NULL)
I realize that I am asking a lot of questions, but I have tried to write them so they break down into a few simple questions about each argument that hopefully just need something close to a "yes" or "no" answer.
1. Is the string argument for the first parameter the same form as the text typed into the search field on the Content Library or Smart Content pane? If not, what is it?
2. If I don't want to filter the results, should I pass an empty string or a wildcard as the first argument?
3. I assume that each category in the QStringList passed as the second argument is the full path of the category (eg "/Default/Hair/Long"). Is this correct? Is it case sensitive, is '/' the correct delimiter, do I need a leading '/', etc?
4. If I pass more than one category, will the method return all assets in either category or all assets in both (union or intersection)? Can I force it to be the intersection if union is the default?
5. What should I pass if I want the search to return assets in any category? Empty list, null, a wildcard, a list every known category, something else?
6. For compatibilityBases, I assume I should pass a list of strings of the form that appear in the Content DB Editor, eg "/Genesis 8/Female". Is this correct? Again, is it case sensitive, is '/' the correct delimiter, do I need a leading '/', etc?
7. What should I pass if I want the search to return assets with any compatibility base? Empty list, null, a wildcard, a list every known compatibility base, something else?
8. For contentTypes, I assume I pass a list of strings like "/Follower/Hair". Again,Is this correct, is it case sensitive, is '/' the correct delimiter, do I need a leading '/', etc?
9. What should I pass if I want the search to return assets of any content type? Empty list, null, a wildcard, a list every known compatibility base, something else? (I'm not sure that I would need to do this, but it would be good to know)
10. Does the method return the union or the intersection of the assets that "match" each string in the list of strings pssed as each argument? For example, do I get the union or intersection of assets in each of the categories in the list passed to the categories parameter? Similarly, do I get the union or intersection of assets that match the list of categories, assets that match the list of compatibility bases and assets that match the list of content types?
Thanks in advance
Comments
This is precisely the kind of semantics that you can't infer from the "documentation" or from the signatures in the headers and that even though a dev could tell you everything you wanted to know in 30 seconds, you'll probably have to waste god-knows how much time figuring it out by experimentation.
To help, I made a plugin to load/unload another plugin, so at least you won't have to restart DS after each educated guess.
I hope you can crack it, and please post back whatever you discover, to save others from your pain.
TheMysteryIsThePoint said:
Exactly! I'm hoping a dev will take pity on me and give me a clue. I have run out of ideas for variations to try. To be fair though, I asked on Christmas Eve, so wasn't expecting an immediate reply!
After who-knows-how-many test/modify/restart Daz cycles, I have resorted to experimenting with the corresponding method in the scripting language to see if I can get any insight that I might be able to "port" to C++. Even with the much faster test/modify cycle, I still haven't found the magic incantation.
There are a number of requests in this forum asking how to access Postgres directly. I suspect that many of the requirements that led to these requests could be met by this method if it were documented or the syntax posted here. I have a sneaking suspicion that this method is a fairly thin wrapper around a very flexible and powerful SQL statement.