Re: Generating SQL statements in BL
Marcel van der Boom <[email protected]> Wed, 14 Oct 2009 18:10:20 +0200
| Newsgroups | gmane.comp.cms.xaraya.devel |
|---|---|
| Organization | HS-Development BV |
| Message-ID | <[email protected]> |
--===============2071036737== Content-Type: multipart/signed; micalg=SHA1; boundary="Sig_/+L=VltRWaWqd59URfwhlAxm"; protocol="application/pkcs7-signature" --Sig_/+L=VltRWaWqd59URfwhlAxm Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Wed 14-Oct-2009 17:35 "[email protected]" <[email protected]> wrote: > Been thinking of this a bit, and I guess I don't quite understand it. > What are the specific consequence of being more or less "declarative"? It's perhaps the case that declarative does not describe it properly but the distinguishing marks I had in mind were these: - the definition is a one-time thing vs selects are executed many times; this has consequences on what strategies you use (for parsing for example: 'time spent doing it' is totally irrelevant in the first, but critical in the second) - the defined things typically have little or no variable data, whereas basically every select worth talking about does have variable things; - Query statements are typically transient, that is you can typically not point at a storage location where "the select" is stored as an object. (this tends to get less true when using more sophisticated elements in an RDBMS like views, triggers and stored procedures) All these are not saying it's impossible to define an XML dialect/subspace to model the "SELECTS" (in fact, with DDL i was originally planning to do something similar to that, i.e. DDL-static and DDL-runtime, but I quickly found out that even the static parts alone were almost too complex for the amount of time i was able to put in. > If I can characterize a result set through a SELECT statement, even=20 > without actually executing the operation, is that not declarative? I guess, but I rather see it as something that comes and goes. > After all it's not like we're specifying how to get the data. Or am I > missing something here? For me the main difference is I think what gets stored as a definition (tables, columns, views etc.) vs things that are used during runtime. But, having said the above, isn't the main point that SQL as such does not belong in templates? If I found myself doing an SQL statement in XML in a template I'd probably define a tag or a method to do the work for me and gain a bit of semantics over SQL. marcel --=20 Marcel van der Boom -- http://hsdev.com/mvdb.vcf HS-Development BV -- http://www.hsdev.com So! web applications -- http://make-it-so.info Cobra build -- http://cobra.mrblog.nl --Sig_/+L=VltRWaWqd59URfwhlAxm-- --===============2071036737== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xaraya_devel mailing list [email protected] http://xaraya.com/mailman/listinfo/xaraya_devel --===============2071036737==--