unknown
1970-01-01 00:00:00 UTC
I can think of a bunch of different implementation strategies. I'm not
familiar enough with SQL/MySQL to know which would work best:
- You could generate code like:
where ? and (dateOfBirth - now > ? years)
Then just supply parameters of false and 0 when the parameter is
missing.
- You could use a temporary tables (i.e. CREATE TEMPORARY TABLE), and
then the C code executes a separate select into a temporary table for
each query parameter that is supplied.
- You could lazily create a separate prepared statement for each
distinct subset of query parameters.
However, I think a low level format whose purpose is to be the compile
target of a high level format is going to be a bit different from the
current approach, which was designed a standalone format. Also I think
it's going to be difficult to get the low-level format to work right as
the compile target of the high level format without implementing them
both at the same time.
Some more random thoughts on this:
- Knowledge of the database schema should be applied at the high-level
and not at the low-level. At the low-level everything should be
explicit. The low-level should explicitly specify the XML format for
the input and the output (though it doesn't necessarily have to use XSD
directly in all cases). It's the job of the tooling to take the database
schema and the high-level format and determine the XML input/output
formats.
- Being explicit about everything in the low-level is going to make the
low-level inconvenient for hand-authoring.
- While the high-level format should offer a unified WSDL/REST approach,
I don't see any benefit to unification at the low-level; I would
envisage separate low-level formats for WSDL and REST.
- We shouldn't ship something consisting of just the low-level part. We
need to ship something that gives at least a glimpse of all the key
parts of the whole vision (both low and high level, both WSDL and REST,
and Atom if at all possible).
- If the XML input/output format is made explicit in the low-level
format, then we can make the XML handling in the low-level part more
general. In particular, I suspect XSLT can be leveraged effectively as
well as XPath.
for use as the WSDL half of the low-level format are as follows:
a) I don't think the proposed solution to handling references works. as
the comment in the wiki suggests (I can't see the Strawman Proposal it
refers to). A powerful and flexible method would be to use XSLT and to
provide an XSLT extension element that allows callouts to SQL. The
input to the XSLT is the flat representation of the list of fields, and
the XSLT turns it into the appropriate hierarchy. The thing that
bothers me about both this and the current approach is that it would
seem to force a nested SQL query for each row of the result, which seems
like a lot of round-trips to the SQL server.
b) I don't see anything in the current approach to handle operations
with rich input structures. We seem to be forcing an RPCish model using
fine-grained operations taking simple parameters. For example, if we
want to be able to support an addCustomers operation that takes a
complex, nested XML structure representing a list of customers to be
added, how is that turned into the appropriate SQL INSERT/UPDATE
statements? One approach might be for the config to specify an XSLT
that maps the XML input into a XML representation of the table inserts
and updates that are needed.
James
familiar enough with SQL/MySQL to know which would work best:
- You could generate code like:
where ? and (dateOfBirth - now > ? years)
Then just supply parameters of false and 0 when the parameter is
missing.
- You could use a temporary tables (i.e. CREATE TEMPORARY TABLE), and
then the C code executes a separate select into a temporary table for
each query parameter that is supplied.
- You could lazily create a separate prepared statement for each
distinct subset of query parameters.
Now to the real question: how do we go forward?
The current approach (that I wrote up) is clearly a lower level user
experience than what you have in mind. It seems to me (at a first pass
level) that your approach can be implemented by "compiling" down to the
current approach. That is, one could take a declarative expression of this
higher level thing and effectively generate the current description as the
"script" to execute to get the desired data resources and/or services.
It also seems to me that the ideal thing to do would be to use the new
approach for tooling and use the current approach for execution.
I think this sort of high level/low level split makes good sense.The current approach (that I wrote up) is clearly a lower level user
experience than what you have in mind. It seems to me (at a first pass
level) that your approach can be implemented by "compiling" down to the
current approach. That is, one could take a declarative expression of this
higher level thing and effectively generate the current description as the
"script" to execute to get the desired data resources and/or services.
It also seems to me that the ideal thing to do would be to use the new
approach for tooling and use the current approach for execution.
However, I think a low level format whose purpose is to be the compile
target of a high level format is going to be a bit different from the
current approach, which was designed a standalone format. Also I think
it's going to be difficult to get the low-level format to work right as
the compile target of the high level format without implementing them
both at the same time.
Some more random thoughts on this:
- Knowledge of the database schema should be applied at the high-level
and not at the low-level. At the low-level everything should be
explicit. The low-level should explicitly specify the XML format for
the input and the output (though it doesn't necessarily have to use XSD
directly in all cases). It's the job of the tooling to take the database
schema and the high-level format and determine the XML input/output
formats.
- Being explicit about everything in the low-level is going to make the
low-level inconvenient for hand-authoring.
- While the high-level format should offer a unified WSDL/REST approach,
I don't see any benefit to unification at the low-level; I would
envisage separate low-level formats for WSDL and REST.
- We shouldn't ship something consisting of just the low-level part. We
need to ship something that gives at least a glimpse of all the key
parts of the whole vision (both low and high level, both WSDL and REST,
and Atom if at all possible).
- If the XML input/output format is made explicit in the low-level
format, then we can make the XML handling in the low-level part more
general. In particular, I suspect XSLT can be leveraged effectively as
well as XPath.
Let's see what you think about that before digging deeper into how that
might work.
Also, your thoughts on the problems with the current approach would be
appreciated since we need to get that working too.
The two major problems that I would see in adapting the current approachmight work.
Also, your thoughts on the problems with the current approach would be
appreciated since we need to get that working too.
for use as the WSDL half of the low-level format are as follows:
a) I don't think the proposed solution to handling references works. as
the comment in the wiki suggests (I can't see the Strawman Proposal it
refers to). A powerful and flexible method would be to use XSLT and to
provide an XSLT extension element that allows callouts to SQL. The
input to the XSLT is the flat representation of the list of fields, and
the XSLT turns it into the appropriate hierarchy. The thing that
bothers me about both this and the current approach is that it would
seem to force a nested SQL query for each row of the result, which seems
like a lot of round-trips to the SQL server.
b) I don't see anything in the current approach to handle operations
with rich input structures. We seem to be forcing an RPCish model using
fine-grained operations taking simple parameters. For example, if we
want to be able to support an addCustomers operation that takes a
complex, nested XML structure representing a list of customers to be
added, how is that turned into the appropriate SQL INSERT/UPDATE
statements? One approach might be for the config to specify an XSLT
that maps the XML input into a XML representation of the table inserts
and updates that are needed.
James