Henner Kollmann wrote:
>
> Hi all!
>
Hi Henner,
I think it would not be bad to extend the documentation of what you
propose to answer the following question. Please don't touch your code,
just extend the documentation. Maybe you answer in form of a section
for the manual, the documentation has to be written anyway.
- from our (long) discussion on the developer's list we know
that what you propose is conceptually somewhere between a
sql database view and a parametric query. It must be clear
where the difference between a database view and this view
is, and which parts of the underlying query can be
manipulated at application runtime.
For the problem you had you needed the where clause to
be flexible. Please make clear what else...
- When we formulate selections within dbforms, we can use
- whereClause
- searchFields
- filters
If we had a sql view containg 'group by ... having ', all
where clauses of queries using the view would in the end
be on the level of the having clause of the underlying query
(that was your problem).
Which of the above dbforms features can still be used and
what is the semantic of such a usage? What has to be done
to extend the where clause/having clause?
You write:
> 1. <view name="my_view"
> from="my_table"
> >
> field="field1" type="integer"
> field="field2" type="integer"
> search="searchfield1" type="integer"
> search="searchfield2" type="integer"
> </view>
>
> Will result in:
> select
> field1,
> field2
> from
> my_table
> where
> searchfield1="xxx" and/or searchfield2="xxx"
>
But where do these "xxx" come from?
How can I do a
select field1, sum(field2)
where field2 > 44
group by field1
having avg(field2) < 120
extending where and having clause at runtime?
You seem to use your searchfields for that, but it's not
clear to me how this will work. What will I have to do to use
the same column within where and having clause?
- Is this concept capable of handling joins, may one write
<view name="viewname"
from="tabl1 left join table2 on table1.id = table2.id" ....> ?
If yes, what happens if I try to update such a view?
- What about keys? The keys of a group by query are the
columns within group by, must that be set so by developers?
- One of the most important thing when introducing views
is the question if and when a view is updatable. Surely a
view containing aggregate functions or a join between
two table connected via an 1-n relationship cannot
be updatable. What are the rules here?
You seem to be able to use the build in update mechanism
of dbforms. What has to be done to be able to do so?
> Next step could be to make the view updateable - this could be easily
> done introducing new tags for update and insert statments. I would
> implement this at the time i need it.
If it really so easy, why don't you document and implement it now?
And I'm not really sure that a general solution would be easy...
you would need a type of template or parameter mechanism within
the sql statements and sometimes could need features sql is perhaps not
capable of...maybe a sequence of statements, branching...
Even if you don't want to implement it, I'd like to see a
documentation of how this could look like.
Luca proposed an extension to override the build in event handlers
for database updates with something written by developers. Wouldn't
your suggestion be a special case of it? If we can pass parameters to
these handlers, using Luca's proposal one could write
<view name="..." from="..."
updateHandler="foo.bar.myUpdateHandler"
updateHandlerParameter1="update .dfad..asdjblabla"
updateHandlerParameter2="insert... .dfad..asdjblabla"
deletehandler="..."
>
Isn't that a more general concept that could also be used
for these views?
Regards
Dirk
-------------------------------------------------------
This SF.net email is sponsored by: ApacheCon, November 18-21 in
Las Vegas (supported by COMDEX), the only Apache event to be
fully supported by the ASF. http://www.apachecon.com
_______________________________________________
DbForms Mailing List
http://www.wap-force.net/dbforms
