On Sun, May 2, 2010 at 9:26 AM, Samisa Abeysinghe <[email protected]> wrote:
> > > On Sun, May 2, 2010 at 9:20 AM, Amila Suriarachchi <[email protected]> wrote: > >> >> >> On Sun, May 2, 2010 at 7:28 AM, Samisa Abeysinghe <[email protected]>wrote: >> >>> Some comments on generated DBS file: >>> >>> 1. Query IDs: Are we using camel case? e.g. >>> selectAll_jk_test_table_1Query. I understand the table name >>> is jk_test_table_1 (and yes we can have anything here, as it comes from the >>> DB). But why do we have "selectAll_" as prefix and "Query" as suffix and not >>> "_Query". Same applied to other query types as well. >>> 2. Should we have "select_all_" as prefix and "_query" as suffix? >>> Basically, all lower case. Same applied to other query types as well. >>> 3. "selectAll" vs "selectFrom". I do not think "selectFrom" is the >>> correct prefix. Because, even "selectAll" uses "SELECT * FROM" in the query. >>> The main difference between them is "WHERE". So why not use "selectWhere", >>> (or "select_where" as per 2) here? "selectFrom" confused me when I had a >>> first look at the dbs, and I had to look back at select all, to understand >>> the difference. We should also consider something like "select_with_key" as >>> prefix for this, as that makes it more readable >>> 4. Why use "add_" for INSERT and not "insert_" as the prefix. That looks >>> out of the bunch as all other operations use the same SQL keyword as >>> operation prefix >>> 5. The same concerns raised from 1 to 4 above apply to operation IDs as >>> well, except for the operation name suffix >>> 6. Why not use "_operation" or at least "_op" as suffix for operation >>> name? >>> >> >> First I think no need to use the table name either in dbs/query or >> wsd/operation since these operations under the service which has the table >> name. >> > > But the point is, that we can have the user first generate this and then > customize it to suite their needs. What if the DB had only 5 tables, and the > user generated the DBS files and copied all those into one to make one > service? > For this problem my suggestion is to improve the data services dbs file to have many services like in services xml. My point is we should not think a service as an arbitrary collection of operations. Operations of a service should be related. I think that improve the readability of the both wsdl and dbs. Anyway this depends on the scope we going to define for a service. table or a whole database. > > I think it is not a good idea to assume that the generated file would be > used as it is... and it is good to have the table name in that case. > > >> What we have is a standard five queries/operations. This can either be >> select/selectAll/insert/delete/update or get/getAll/put/delete/post if >> thinking in REST way. >> All operation names can be suffixed as Query in dbs and Operation in wsdl. >> >> For select operation I think it is enogh to say select becuse both in dbs >> and wsdl it implies this opeation takes an input parameter. >> > > Well, we are assuming Web services knowhow in this case I guess - it is > good to have that info in there for the sake of folks who do not understand > Web services like DBAs. > Anyway there is no harm adding some suffix for select operation. What I think of in the web service consumers point of view. The only thing the see is the wsdl. Therefore the generated wsdl should be self descriptive and better to follow the common patterns. For DBAs they kind of know what type of service they generate and what type of operations they should expect. (May be reading the documentation :) ) thanks, Amila. >> eg. when there is a method select(int i) or get(int i) it implies that the >> parameter passing is some thing unique to return object. >> >> >> >>> 7. Why not use "_data_service" or at least "_ds" as suffix for service >>> name rather than just the table name? For e.g. if table name was >>> "wes_client" make the service name "wes_client_data_service" >>> >> >> For this we can have an option to let users to define the service name as >> well. >> > > +1 > > >> >> For default case I think it is enogh to have the Service suffix. What web >> service consumer sees is the wsdl, for him no need to show how the service >> is generated. >> > > However, if you look at the service manager's service linsting page, it > would be easy to have it say it is "data_service" so that it tells you at a > glance that it is a DS. > > Thanks, > Samisa... > > > >> >> thanks, >> Amila. >> >>> >>> In summary, we need consistency and also focus on readability, for the >>> sake of maintainability, of the DBS. We cannot rule our someone trying to >>> read this and understand what it is all about. I presume users will use this >>> as the first step and then customize this manually to suite their needs. >>> >>> May be we should define some best practices to be followed when >>> implementing DBS files, in general, and follow those guidelines in the >>> generated file as well. >>> Not sure if we already have guidelines on how to write a good DBS - if >>> not we can make that part of this effort. >>> >>> Thanks, >>> Samisa... >>> >>> >>> On Sat, May 1, 2010 at 10:16 PM, Jasintha Dasanayaka >>> <[email protected]>wrote: >>> >>>> Hi >>>> >>>> Here I attached both wsdl and dbs which generated for one table >>>> service. >>>> >>>> Thanks >>>> Jasintha >>>> >>>> >>>> On Sat, May 1, 2010 at 1:49 PM, Amila Suriarachchi <[email protected]>wrote: >>>> >>>>> hi, >>>>> >>>>> Can you please send the generated wsdl for one table service? >>>>> >>>>> I am not sure how you have done it. Here you can nicely map insert, >>>>> delete, update, select to four operations called put, delete, post and >>>>> get. >>>>> Then expose it as restful service[1]. >>>>> >>>>> [1] http://wso2.org/library/3726 >>>>> >>>>> thanks, >>>>> Amila. >>>>> >>>>> >>>>> >>>>> >>>>> On Fri, Apr 30, 2010 at 2:48 PM, Jasintha Dasanayaka < >>>>> [email protected]> wrote: >>>>> >>>>>> Hi All >>>>>> >>>>>> I have finished the development of all the basic functionality of the >>>>>> UI wizard. Some screen shots are attached. >>>>>> >>>>>> Thanks >>>>>> Jasintha >>>>>> >>>>>> On Fri, Apr 23, 2010 at 2:50 PM, Jasintha Dasanayaka < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> It's a wizard. Following are the usage scenarios. >>>>>>> Create >>>>>>> 1. Select a data source >>>>>>> 2. Select set of database objects of this data source >>>>>>> 3. Generate data services for selected objects >>>>>>> >>>>>>> View/Edit >>>>>>> 1. Select a data source & view existing data services created for >>>>>>> it's objects. >>>>>>> >>>>>>> thanks >>>>>>> Jasintha >>>>>>> >>>>>>> >>>>>>> On Fri, Apr 23, 2010 at 2:33 PM, Samisa Abeysinghe >>>>>>> <[email protected]>wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Fri, Apr 23, 2010 at 2:20 PM, Jasintha Dasanayaka < >>>>>>>> [email protected]> wrote: >>>>>>>> >>>>>>>>> Hi All >>>>>>>>> >>>>>>>>> I am developing a new feature for data-service .It can uses >>>>>>>>> to generate data services for given database. It generates data >>>>>>>>> services for whole database. >>>>>>>>> >>>>>>>>> It generates one service per one table that service has basic >>>>>>>>> database operations(Insert, Delete, Update, Select by key and Select >>>>>>>>> all). >>>>>>>>> >>>>>>>>> >>>>>>>>> This feature basically has two parts ,UI part and the back end >>>>>>>>> part.The back end part of the feature I have already developed now i >>>>>>>>> am >>>>>>>>> developing the UI part of the feature. >>>>>>>>> I expect to complete this UI part with in the next week >>>>>>>>> >>>>>>>> >>>>>>>> What does the UI do? I mean does it allow configuring, or viewing, >>>>>>>> or is it a Wizard?? >>>>>>>> >>>>>>>> Samisa... >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> thanks >>>>>>>>> Jasintha >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Jasintha Dasanayaka >>>>>>>>> email: [email protected] >>>>>>>>> cell: +94 772 916 596 >>>>>>>>> blog: http://jasintha.org >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Carbon-dev mailing list >>>>>>>>> [email protected] >>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev >>>>>>>>> >>>>>>>>> -- >>>>>>>> Samisa Abeysinghe >>>>>>>> Director, Engineering - WSO2 Inc. >>>>>>>> >>>>>>>> http://wso2.com/ - "lean . enterprise . middleware" >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Carbon-dev mailing list >>>>>>>> [email protected] >>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Jasintha Dasanayaka >>>>>>> email: [email protected] cell: +94 772 916 596 >>>>>>> blog: http://jasintha.org >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Jasintha Dasanayaka >>>>>> email: [email protected] cell: +94 772 916 596 >>>>>> blog: http://jasintha.org >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Carbon-dev mailing list >>>>>> [email protected] >>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Carbon-dev mailing list >>>>> [email protected] >>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev >>>>> >>>>> >>>> >>>> >>>> -- >>>> Jasintha Dasanayaka >>>> email: [email protected] cell: +94 772 916 596 >>>> blog: http://jasintha.org >>>> >>>> >>>> _______________________________________________ >>>> Carbon-dev mailing list >>>> [email protected] >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev >>>> >>>> -- >>> Samisa Abeysinghe >>> Director, Engineering - WSO2 Inc. >>> >>> http://wso2.com/ - "lean . enterprise . middleware" >>> >>> >> -- > Samisa Abeysinghe > Director, Engineering - WSO2 Inc. > > http://wso2.com/ - "lean . enterprise . middleware" > >
_______________________________________________ Carbon-dev mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
