iquest reads query from stdin about irods_client_icommands

[trel]

So, if implemented... this would also work with a pipe into the front...

echo "select DATA_RESC_NAME" | iquest --no-page '%s'

AND reading in from a file?

iquest --no-page '%s' < tonyfile.txt

Would we require a new flag? Or just... accept/parse stdin if there is no selectConditionString present?

[tedgin]

I don't think you would need a new flag. If a selectConditionString isn't provided on the command line, see if one is provided via stdin.

[mcast]

I would prefer requiring a flag (--stdin=select) and/or placeholder (selectConditionString == '-') for these reasons,

1. users hitting this code accidentally will find it hangs awaiting stdin, and that can be more confusing than a timely error
2. in a future expansion the format string might arrive another way, such as stdin. If absense of selectConditionString is interpretted as a mode switch, you're kind of... nibbling your syntactic space from both ends, so possibly ending up with more confusion later?
3. a related extension which could reduce the caller's associated code is ? placeholders in the selectConditionString, hence
   • printf "/COLLECTION/BOBBY\nTABLES.dat\n" | iquest --stdin=args %s "select DATA_ID where COLL_NAME = ? and DATA_NAME = ?"
   • this has a security benefit: reducing the chances of attacks similar to SQL injection, by taking the responsibility for "not getting it wrong" off the caller into the code which has a test suite. 😄
   • (I realise that the currently read-only AND-only logic doesn't leave much room for useful injection attacks, but I bet it's possible to probe other data in a series of repeated attacks)

---

If you're looking for features, here's an idiom I like for better performance on bulk queries,

mca@casm3-head2:~$ seq 21 | id-n-at-a-time -n5 -q -J,
'1','2','3','4','5'
'6','7','8','9','10'
'11','12','13','14','15'
'16','17','18','19','20'
'21'
mca@casm3-head2:~$ for args in $( seq 21 | id-n-at-a-time -n5 -q -J, ); do iquest %s/%s "select COLL_NAME, DATA_NAME where DATA_ID in ($args)"; done
CAT_NO_ROWS_FOUND: Nothing was found matching your query
CAT_NO_ROWS_FOUND: Nothing was found matching your query
CAT_NO_ROWS_FOUND: Nothing was found matching your query
CAT_NO_ROWS_FOUND: Nothing was found matching your query
CAT_NO_ROWS_FOUND: Nothing was found matching your query

id-n-at-a-time is a local quick hack, and I normally run about 500 args in the group. Some databases don't like a lot of placeholder args and when last I looked, iquest didn't document its limit.

OK, I have no files there and so I'm bumping #282... but a feature that wraps this up might be useful to others and stdin is the place to feed it.

Something like seq 21 | iquest --stdin=in-args %s/%s "select COLL_NAME, DATA_NAME where DATA_ID in (??)" perhaps?

Or another way: if the stdin feed is JSON and the placeholders are :named?

These are idle ponderings rather than official feature requests.

[tedgin]

What @mcast says makes sense to me. I agree that either a - placeholder should be used for the selectConditionString or a flag should be set. Query value placeholders would be neat too, but that should probably become an independent feature request.

[trel]

I like the - as well, it removes the ambiguity and the 'nibbling'.