Open barny opened 1 year ago
For -s this is probably not very obvious, plus there's an issue with -n/-v
Names of attributes have to be surrounded by ' so they are looked up, and also you have to defeat your commandline method for quoting spaces in values. On Windows this means that for an attribute called a space
you specify -s "'a space'"
However the processing for -n/-v is different, primarily because the -n/-v values are used two ways; they are put onto the oslc.select list to ensure values (or not) are retrieved for post-filtering, and this needs them to be surrounded by ' like -s values, BUT then during the postprocessing the -n/-v alues are used literally to match column headings which themselves don't have ', so they never match.
At the moment if you can use explicit -s *
you can use -n/-v with attribute names with a space in them just by using " around them like -v "a space"
. They work with -s *
because the * suppresses adding -n/-v names to oslc.select, so they're not formally parsed.
There's a simple hacky fix which is to require ' for -n/v names and strip ' off for post-processing, or a compromise hacky fix which is to detect whether they have ' and if not then add them. The best fix might be to require the ' and parse them like -s does, which will also detect if you misnamed the -n/-v value so I think that's my preferred solution.
It worked with QM but when trying to use it on a Global configuration with RM it gives me the next error:
oslcquery -J https://doorsng.grupoantolin.com:9443/ -U -P -A rm,gc,jts:jts23 -p "JEEP KM NA24 AmbLp" -E "JEEP KM NA24 AmbLp (GC)" -G "JEEP KM NA24 AmbLp MASTER V1.0" -s * -O Result.csv
querying for gc config JEEP KM NA24 AmbLp MASTER V1.0 Loading DN shapes: 100%|███████████████████████████████████████████████████████| 170/170 [01:06<00:00, 2.57 results/s] Preparing Query Exception on executing request. URL: https://doorsng.grupoantolin.com:9443/rm/views, 400, <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:err="http://jazz.net/xmlns/prod/jazz/foundation/1.0/">
That error is a new one on me; DB2 is complaining the query is just too big:
54004 | The statement has too many table names or too many items in a SELECT or INSERT list. -- | --You've got past authentication because the DN shapes load, also the GC has been resolved to a configuration URL. A similar query (although for a much smaller project) works for me. I've now used oslcquery on very large multi-component queries (ELM on DB2) without hitting this.
I just published version 0.17.0, can you update and try with this?
0.17.0 should have resolved the -n/-v problems :-)
What version+ifix are you using?
Does it work any better if you don't use -s *
? Or if you use one of the local configuration for a contribution from RM rather than a GC?
I am currently using the last one 0.17.0. It still gives the same error when trying to query for all the artifacts with artifact type==X inside the global configuration. So I tried to query for all the artifacts with artifact type==X inside each component in the project, with the local configuration for each of them. In most of the cases the query is accepted and the file generates, but I am getting errors in some of them, like this one F.E:
oslcquery -J https://doorsng.grupoantolin.com:9443/ -A rm,gc,jts:jts23 -U -P -p "JEEP KM NA24 AmbLp" -C "JEEP KM NA24 AmbLp - MASTER Technical Specification" -s * -F "JEEP KM NA24 AmbLp - MASTER Technical Specification_V2.0" -O "Archivos/JEEP KM NA24 AmbLp - MASTER Technical Specification.csv" -q "((oslc:instanceShape='SYS Non-Functional Requirement') || (oslc:instanceShape='SYS Functional Requirement') || (oslc:instanceShape='SW Non-Functional Requirement') || (oslc:instanceShape='SW Functional Requirement') || (oslc:instanceShape='SW Low Level Requirement'))"
Exception on retrying request. URL: https://doorsng.grupoantolin.com:9443/rm/cm/stream/_OtxhALKBEe2vAsz6Mdt4cg, 404,
GLC self=<elmclient._rm._RMComponent object at 0x000001CE7FA93DC0> name_or_uri='JEEP KM NA24 AmbLp - MASTER Technical Specification_V2.0'
Loading DN shapes: 100%|███████████████████████████████████████████████████████████| 9/9 [00:00<00:00, 17.61 results/s]
Preparing Query
Identifier s=['oslc:instanceShape']
Identifier s=['oslc:instanceShape']
Identifier s=['oslc:instanceShape']
Identifier s=['oslc:instanceShape']
Identifier s=['oslc:instanceShape']
Query completed in 1 page(s)
Querying : 100%|██████████████████████████████████████████████████████| 322/322 [00:01<00:00, 100.59 results/s]
Query completed in 2 page(s)
Processing : 0%| | 0/455 [00:00<?, ? results/s]Traceback (most recent call last):
File "C:\Program Files\Python39\Scripts\oslcquery-script.py", line 33, in
The -n/ -v problems still exist so I dont know how to get the data. I am currently getting this error I posted in 5/18 components from a project.
I have tried also without the query but the response is the same
When quering into my STK requirements component I get a different error message:
oslcquery -J https://doorsng.grupoantolin.com:9443/ -A rm,gc,jts:jts23 -U -P -p "JEEP KM NA24 AmbLp" -C "JEEP KM NA24 AmbLp STK" -s * -F "JEEP KM NA24 AmbLp STK_V2.0" -O "Archivos/JEEP KM NA24 AmbLp STK.csv"
Exception on retrying request. URL: https://doorsng.grupoantolin.com:9443/rm/cm/stream/_OtxhALKBEe2vAsz6Mdt4cg, 404,
GLC self=<elmclient._rm._RMComponent object at 0x000001DC5BEE3940> name_or_uri='JEEP KM NA24 AmbLp STK_V2.0'
Loading DN shapes: 100%|█████████████████████████████████████████████████████████| 13/13 [00:00<00:00, 24.31 results/s]
Preparing Query
Traceback (most recent call last):
File "C:\Program Files\Python39\Scripts\oslcquery-script.py", line 33, in
There may be several issues you're hitting, because you have three different failures.
You're trying to query for all artifacts of a particular type across multiple contributions in a GC. Each of these type definitions has a unique local URI in each component. Unfortunately elmclient/oslcquery doesn't currently handle this. If your types all have RDF URIs, and if elmclient/oslcquery discovered the typesystem for each contribution then it may be possible to make this type of query work, but that's a lot of work and not in scope for elmclient which is really only intended as a demonstrator for the APIs, i.e. it's not intended as a comprehensive solution for all needs.
However oslcquery should work in a local configuration, like your last example querying STK requirements component. It looks like something about the XML coming back from DOORS Next is badly formed at line 160 column 95. You can capture a complete trace of the communication by adding -L TRACE
to your commandline - this will produce in a subfolder logs
a file named for the date/time like elmclient-20230316-09202.log which shows every GET and response including headers and body content - NOTE this will include your username and password so delete after use! The end of the file will show the last XML received, probably the response to the OSLC query, which has some odd content at line 160 column 95.
For this query, does it work any better if you don't use -s *
?
FYI your query specification -q "((oslc:instanceShape='SYS Non-Functional Requirement') || (oslc:instanceShape='SYS Functional Requirement') || (oslc:instanceShape='SW Non-Functional Requirement') || (oslc:instanceShape='SW Functional Requirement') || (oslc:instanceShape='SW Low Level Requirement'))"
will require five OSLC Query calls to be made, one for each of the sections of your -q. It will be much quicker/easier and only require one OSLC Query if you use:
-q "oslc:instanceShape in ['SYS Non-Functional Requirement','SYS Functional Requirement','SW Non-Functional Requirement','SW Functional Requirement','SW Low Level Requirement']"
Another FYI - those command lines are long/complicated aren't they. It's possible to put all the query information in an Excel spreadsheet and run all the queries from the spreadsheet, which requires an awful lot less typing. I use this as a basic regression test before each release. so for example I use batchquery tests\tests_702.xlsx
to run all 50+ tests. The regression aspect is that you can enter the expected number of results for each query. You could use tests.xlsx as a starting point for your own collection of batch queries.
Which version+ifix are you using?
Thank you for your answer, I am using ifix0x13. From now on I will use this structure -q "oslc:instanceShape in ['SYS Non-Functional Requirement','SYS Functional Requirement','SW Non-Functional Requirement','SW Functional Requirement','SW Low Level Requirement'].
In my example with STK requirements, it works without a problem if I use the same query without -s *, but then I cannot get the data I want because no attribute information gets displayed. So now I have 2 options:
But both options give me problems right now.
And about the length of the queries I use: Yes they are long and complicated, but I generate them with a python file looping through lists with my component names and stream names, so it would be pretty much the same as using the excel file. But thank you for your suggestion.
works without -s *
I suspect there's some XML data with a bad (as far as elmclient is concerned) XML entity reference in one of the attributes selected by -s *, almost certainly the Primary Text, and probably created by pasting.
Eliminate most other attributes by using -s "'Primary Text'"
- I'd expect you still get the error if the entity ref is in the primary text. if you use the -L TRACE
method I described earlier you the response to the last GET will include this XML. It may be easier to find the line/column now there are fewer attributes being returned. Another way would be to divide and conquer by selecting a subset of artifact IDs like -q "dcterms:identifier>1000 and dcterms:identifier<2000"
(or whatever range of identifiers gives you roughly half the previous results) and if no error then use the other half range; when you get an error keep dividing that range by two until you reduce to a very small number of identifiers or just one that gives an error. If you can show me the entityref or ideally the complete XHTML of the problem artifact that may help identify the problem.
oslcquery -J https://doorsng.grupoantolin.com:9443/ -A rm,gc,jts:jts23 -U -P -p "JEEP KM NA24 AmbLp" -C "JEEP KM NA24 AmbLp STK" -s "'Primary Text'" -F "JEEP KM NA24 AmbLp STK_V2.0" -O "Archivos/JEEP KM NA24 AmbLp STK.csv" -L TRACE
GLC self=<elmclient._rm._RMComponent object at 0x000001BC6482BB50> name_or_uri='JEEP KM NA24 AmbLp STK_V2.0'
Loading DN shapes: 100%|████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████| 13/13 [00:03<00:00, 3.61 results/s]
Preparing Query
Traceback (most recent call last):
File "C:\Program Files\Python39\Scripts\oslcquery-script.py", line 33, in
'Primary Text',dcterms:identifier,rm_nav ^ Expected one of:
That looks reminiscent of output from the version before I fixed the single-quote problem with -s
. Your pasted text doesn't show the version you're using - it should show as first line printed Version 0.17.0
- so please check you're using that latest version.
A very similar command works for me using 0.17.0:
oslcquery -A rm,gc -p rm_gc_p1 -s "'Primary Text'" -E gcproj -G "gccomp Initial Development" Version 0.17.0 querying for gc config gccomp Initial Development Loading DN shapes: 100%|█████████████████████████████████████████████████████████| 46/46 [00:01<00:00, 40.15 results/s] Preparing Query Querying : 100%|████████████████████████████████████████████████████| 1478/1478 [00:01<00:00, 675.07 results/s] Query completed in 8 page(s) Processing : 100%|███████████████████████████████████████████████████| 1478/1478 [00:00<00:00, 3416.46 results/s] Processing completed Query result has 1478 entries Runtime was 0m 05s
The line numbers in your traceback definitely don't match version 0.17.0
Discussed in https://github.com/IBM/ELM-Python-Client/discussions/32