Hi
modified wizard will looks like as follows
1st step
Connection form
2nd step
* service generation mode
-single service
-multiple service
* tables selection
3rd step
* operation list
-insert
-delete
-update
-select all
-select with key
*service name generation mode
-default (database_table_name_data_service )
-user define the name of service
final step
show the names of generated service/services
Thanks
Jasintha
On Sun, May 2, 2010 at 4:23 PM, Anjana Fernando <anj...@wso2.com> 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. 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.
>
> > 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.
>
> 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 <am...@wso2.com>
> 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 <am...@wso2.com>
> wrote:
> >>
> >>
> >> On Sun, May 2, 2010 at 9:26 AM, Samisa Abeysinghe <sam...@wso2.com>
> wrote:
> >>>
> >>>
> >>> On Sun, May 2, 2010 at 9:20 AM, Amila Suriarachchi <am...@wso2.com>
> >>> wrote:
> >>>>
> >>>>
> >>>> On Sun, May 2, 2010 at 7:28 AM, Samisa Abeysinghe <sam...@wso2.com>
> >>>> 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
> >>>>> <jasin...@wso2.com> 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 <am...@wso2.com>
> >>>>>> 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
> >>>>>>> <jasin...@wso2.com> 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
> >>>>>>>> <jasin...@wso2.com> 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
> >>>>>>>>> <sam...@wso2.com> wrote:
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> On Fri, Apr 23, 2010 at 2:20 PM, Jasintha Dasanayaka
> >>>>>>>>>> <jasin...@wso2.com> 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: jasin...@wso2.com
> >>>>>>>>>>> cell: +94 772 916 596
> >>>>>>>>>>> blog: http://jasintha.org
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> _______________________________________________
> >>>>>>>>>>> Carbon-dev mailing list
> >>>>>>>>>>> Carbon-dev@wso2.org
> >>>>>>>>>>> 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
> >>>>>>>>>> Carbon-dev@wso2.org
> >>>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> --
> >>>>>>>>> Jasintha Dasanayaka
> >>>>>>>>> email: jasin...@wso2.com cell: +94 772 916 596
> >>>>>>>>> blog: http://jasintha.org
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> --
> >>>>>>>> Jasintha Dasanayaka
> >>>>>>>> email: jasin...@wso2.com cell: +94 772 916 596
> >>>>>>>> blog: http://jasintha.org
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> _______________________________________________
> >>>>>>>> Carbon-dev mailing list
> >>>>>>>> Carbon-dev@wso2.org
> >>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> _______________________________________________
> >>>>>>> Carbon-dev mailing list
> >>>>>>> Carbon-dev@wso2.org
> >>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> Jasintha Dasanayaka
> >>>>>> email: jasin...@wso2.com cell: +94 772 916 596
> >>>>>> blog: http://jasintha.org
> >>>>>>
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> Carbon-dev mailing list
> >>>>>> Carbon-dev@wso2.org
> >>>>>> 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
> > Carbon-dev@wso2.org
> > 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
> Carbon-dev@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
>
--
Jasintha Dasanayaka
email: jasin...@wso2.com cell: +94 772 916 596
blog: http://jasintha.org
_______________________________________________
Carbon-dev mailing list
Carbon-dev@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
