Hi All * * As a next step I am going to handle the *stored procedures of** * the database .According to jdbc meta data API there are two methods to handle the stored procedures . getProcedures-this method returns list of stored procedure in database. getProcedureColumns-this methods provide information about a stored procedure.
Thanks Jasintha On Fri, May 7, 2010 at 7:44 PM, Jasintha Dasanayaka <[email protected]>wrote: > HI All > > Following things are added to the tool > Now it uses carbon data sources for getting the connection information > can generates multiple service(one service per table) as well as the > single service(one service for whole database) . > user can select the service/services generation mode > > Thanks > Jasintha > > > On Sun, May 2, 2010 at 9:38 P M, Anjana Fernando <[email protected]> wrote: > >> On Sun, May 2, 2010 at 8:15 PM, Amila Suriarachchi <[email protected]> >> wrote: >> > >> > >> > 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. >> > >> >> Yeah. >> >> >> >> >> 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. >> > >> >> Here I was actually meaning to refer to the idea of introducing >> special syntax for the RDBMS based data services, i.e. <tableService >> tableName="..">, where it is not a generic function common to all type >> of data sources. >> >> >> >> >> > 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. >> > >> >> Yeah, true .. I was thinking along the lines of, if it would be worth >> the trouble of implementing such a thing, considering that, this was >> not part of the initial design of data-services, to expose multiple >> services in a single dbs file .. anyways . I agree with your point :) >> .. >> >> > 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. >> > >> >> Yeah. >> >> > 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) >> >> If I understand what you meant here correctly, yeah that is the >> objective of the tool. It just creates a basic data service for the >> user to start with, this option will most probably be integrated in >> the DS Wizard, where a user is selecting a RDBMS data source, and he >> will be presented with the option to immediately create a data service >> with the default operations (that is without going through the rest of >> the steps in the wizard). >> >> > >> > 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 >> > >> > >> >> >> >> -- >> 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 >> > > > > -- > 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
