Maybe we should change the tag name. I think view would leed to much to database views. What i implement not views. Luca is right. It is something like "declarative parametric queries". But you can not only use them db:select or db:queryData. You can use it like a table in every place you use a table....
Do anyone have a good tag name for "declarative parametric queries"? Regards, Henner > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:jdbforms-interest-admin@;lists.sourceforge.net] On > Behalf Of Luca Fossato > Sent: Monday, November 04, 2002 3:29 PM > To: dbforms-interest mailing list > Subject: Re: [dbforms] New stuff; Views > > > Hi Dirk, hi Henner, > > I think it's better to have a syntax to specify declarative > "parametric queries" > than views. *My .02 euros*: > > DbForms can already use database views: > create a view on your db, then map that view on a dbforms > table into the dbforms > xml config file. Then you can use that view as a normal table > for select > operations (Ok, up to now MySQL doesn't support views...). > > But.... > > views are not "updatable objects" I think every rdbms has got > its rules to > specify how a view can be updated. So, I think that there is > not a default mode > to specify a "view update" operation. You could have a > situation where every > view should use a different "insert" or "update" dbevent class... > > Anyway, Henner's work can be used to specify declarative > queries into the xml > config file. For example, those query "objects" can be used > into db:select or > db:queryData tags... and this is a lot better than specify > sql queries into jsp > views... ;^) > > Luca > > > Dirk Kraemer wrote: > > 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 > > > > > > > > > > > ------------------------------------------------------- > 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 > -----Original Message----- > From: Henner Kollmann [mailto:Henner.Kollmann@;aucos.de] > Sent: Monday, November 04, 2002 3:14 PM > To: 'Luca Fossato' > Subject: RE: [dbforms] New stuff; Views > > > Maybe we should change the tag name. I think view would leed > to much to database views. What i implement not views. Luca > is right. It is something like "declarative parametric > queries". But you can not only use them db:select or > db:queryData. You can use it like a table in every place you > use a table.... > > Do anyone have a good tag name for "declarative parametric queries"? > > Regards, > Henner > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:jdbforms-interest-admin@;lists.sourceforge.net] On > > Behalf Of Luca Fossato > > Sent: Monday, November 04, 2002 3:29 PM > > To: dbforms-interest mailing list > > Subject: Re: [dbforms] New stuff; Views > > > > > > Hi Dirk, hi Henner, > > > > I think it's better to have a syntax to specify declarative > > "parametric queries" > > than views. *My .02 euros*: > > > > DbForms can already use database views: > > create a view on your db, then map that view on a dbforms > > table into the dbforms > > xml config file. Then you can use that view as a normal table > > for select > > operations (Ok, up to now MySQL doesn't support views...). > > > > But.... > > > > views are not "updatable objects" I think every rdbms has got > > its rules to > > specify how a view can be updated. So, I think that there is > > not a default mode > > to specify a "view update" operation. You could have a > > situation where every > > view should use a different "insert" or "update" dbevent class... > > > > Anyway, Henner's work can be used to specify declarative > > queries into the xml > > config file. For example, those query "objects" can be used > > into db:select or > > db:queryData tags... and this is a lot better than specify > > sql queries into jsp > > views... ;^) > > > > Luca > > > > > > Dirk Kraemer wrote: > > > 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 > > > > > > > > > > > > > > > > > > > ------------------------------------------------------- > > 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 > ------------------------------------------------------- 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
