Closed jjacquay712 closed 8 years ago
+1 for this feature as a way to get additional data from iRODS and the iCAT db, e.g total size of files in a collection, etc, plus many other interesting queries that could be done to spice up an iRODS web UI.
Note that the current iquest functionality handles all the appropriate access controls, etc. that may be hard to recreate if GoRods goes a more direct route to accessing the data in the database. It would certainly be easy to query the db directly but that would likely require GoRods to hold the main iCAT db username/password as well as ensure that queries executed on the part of a user only return results that they are allowed to receive.
I'll mark this as high priority, thanks for the input. I don't foresee any issues relating to access control - I typically write the C/C++ code with the icommand code as reference, so it should behave similarly. Even the metadata query code passes through iRods abstractions, so GoRods should never need direct access to the underlying iCAT database.
ORM would overcomplicate things, and iquest doesn't accept real SQL anyway (only a sanitized subset). Left out formatting functionality since that can be written in the application code. Also left out pre-defined SQL functionality (aliases) since the docs recommend not using it:
Generally, it is better to use the general-query (non --sql forms herein) since that generates the proper SQL (knows how to link the ICAT tables) and handles access control and other aspects of security.
https://docs.irods.org/master/icommands/user/#iquest
Idea: ORM/DAO abstraction on top of the functions that accept SQL queries/query fragments. Maybe something similar to ActiveRecord but more iRods specific, like this: