You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The implementation of the server 'retrieve_mappings' call seems rather odd.
It passes info -- and itself -- to queries.valid_ordered_mappings.
Which then ...
constructs a query string
calls the the server back, via the run_query method
returns the data from that back to the caller
Many of the queries behave similarly, though some also perform extra processing of the raw query result at step (3), to make the final return value .
It feels to me like any+all server ('fuseki') methods which make calls into the queries module should not be there at all (retrieve_mappings, validate, save et al.).
In effect, these methods provide management concepts specific to our database structure and/or usage. So that should really be kept separate from the generic server functions.
So, I'd expect (+ much prefer) to see the server module called by the queries module, but never the other way around.
Meanwhile, the existing 'fuseki' enquiry API methods, that I'm objecting to here, might belong in the existing queries module, or possibly in a separate layer that encodes DB usage rather than encoding concepts (I haven't seen enough to grasp it all).
The text was updated successfully, but these errors were encountered:
The implementation of the server 'retrieve_mappings' call seems rather odd.
It passes info -- and itself -- to
queries.valid_ordered_mappings
.Which then ...
run_query
methodMany of the queries behave similarly, though some also perform extra processing of the raw query result at step (3), to make the final return value .
It feels to me like any+all server ('fuseki') methods which make calls into the queries module should not be there at all (retrieve_mappings, validate, save et al.).
In effect, these methods provide management concepts specific to our database structure and/or usage. So that should really be kept separate from the generic server functions.
So, I'd expect (+ much prefer) to see the server module called by the queries module, but never the other way around.
Meanwhile, the existing 'fuseki' enquiry API methods, that I'm objecting to here, might belong in the existing queries module, or possibly in a separate layer that encodes DB usage rather than encoding concepts (I haven't seen enough to grasp it all).
The text was updated successfully, but these errors were encountered: