On Sun, May 2, 2010 at 4:23 PM, Anjana Fernando <[email protected]> wrote:
> Hi, > > > The current implementation has written as an above layer to data services > > which generates the .dbs file. > > Actually this tool, as u mentioned, is intended to be working on a > higher layer. Because, the simple purpose of this tool is to quickly > create a data service with the basic functionality given a RDBMS data > source. Where it is actually expected that the user will customize the > generated data service by adding new queries/operations and removing > existing ones. yes. If the idea of this tool is to generate a scratch dbs file then even we don't have to think much about operation names etc ... Then you can think of what I have suggested as a new feature. > And also to notice is, relational database based data > sources is only one of the possibilities that data services can > handle, where others are excel, csv, gspread etc.. and also can be > easily extended to support other data sources. > I am not clear about what you try to point out. I assume the tool already written is rational db specific. > > > But instead if we can improve the dbs file (hence data services) to add > some thing as follows to have this feature. > > <tableService tableName="table" serviceName="tableService"> > > </tableService> > > If we give such special syntax in the dbs for RDBMS, in my opinion, it > will basically undermine the data sources abstraction we have. And > also, by adding such an option, the user will not be able to control > the operations automatically created by the data services deployer, > and also it will make the current dbs syntax complex, where we now > have a very simple syntax and easy to manage. Also about having many > services in one dbs file, it may create some subtle problems like, how > to manage hot-deployment, because the dbs file was changed, so even if > only a single service is actually changed, all the services will be > re-deployed. And as I see, having one dbs file per service seems > logical. > Letting users to define multiple services in one file is an addition hence it is always advantages. Here it is not a must to have more than one service. They can still deploy one per dbs. They can define multiple services in one file only if it is useful to their scenario. Same as axis2 services.xml. Having different types of services has its pros and corns. As you have mentioned it won't allow to have a data-source abstraction and can lead to different configuration format for different type services. On the other hand it may make simple thing complex. for an example if a user wants to expose a table as a service with default operations still he has to write all the queries by hand. ( this is why you need to provide the tool) thanks, Amila. > > On the topic of having whttp location details for a service, in data > services, we have a separate section on creating "resources" for a > data service, where we can give the resource name and the HTTP method > of accessing those resources. > > Cheers, > Anjana. > > On Sun, May 2, 2010 at 11:08 AM, Amila Suriarachchi <[email protected]> > wrote: > > Let me say some thing I was thinking about this. > > > > Actually I got a similar idea after reading this article[1]. Here Keith > > keeps some Student data > > in memory which should have kept in a data base table. So if we write a > data > > service which generates > > a service as he has given by looking at a database table that would given > a > > practical example to Axis2 restful services. Of cause this can be > accessed > > with soap as well. > > > > The current implementation has written as an above layer to data services > > which generates the .dbs file. > > > > But instead if we can improve the dbs file (hence data services) to add > some > > thing as follows to have this feature. > > > > <tableService tableName="table" serviceName="tableService"> > > > > </tableService> > > > > I assume dbs deployer can generate the service with whttp location > details > > for this kind of service. > > > > And also this solves the problem samisa has mentined. Now DBA don't have > to > > copy the generated dbs files but just have to put an entry for the tables > he > > need to generates the services. > > > > thanks, > > Amila. > > > > [1] http://wso2.org/library/3726 > > > > On Sun, May 2, 2010 at 10:29 AM, Amila Suriarachchi <[email protected]> > wrote: > >> > >> > >> 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 > > > > > > > > -- > Anjana Fernando > Software Engineer > WSO2, Inc.; http://wso2.com > lean.enterprise.middleware >
_______________________________________________ Carbon-dev mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
