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==--