Bugzilla – Full Text Bug Listing
| Summary: | Extend New Service and Library wizards for database access | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | z_Archived | Reporter: | Will Smythe <smythew> | ||||||||||
| Component: | EDT | Assignee: | Song Fan <songfan> | ||||||||||
| Status: | CLOSED FIXED | QA Contact: | |||||||||||
| Severity: | enhancement | ||||||||||||
| Priority: | P1 | CC: | chenzhh, jinfahua, mayunf, opepermans, pharmon, songfan, svihovec, tdramsey, tww | ||||||||||
| Version: | unspecified | ||||||||||||
| Target Milestone: | --- | ||||||||||||
| Hardware: | All | ||||||||||||
| OS: | All | ||||||||||||
| Whiteboard: | |||||||||||||
| Bug Depends on: | 370388, 370672, 370910, 367259, 367260, 370395, 370673 | ||||||||||||
| Bug Blocks: | 363081 | ||||||||||||
| Attachments: |
|
||||||||||||
|
Description
Will Smythe
Due to the fact that this line item is intended to cover a high level topic, I believe it should only be targeted at the .8 milestone (assuming we think all of the work will be finished in the .8 time frame). As we design this feature, new work items can be added and targeted at a specific iteration. Technically, I would prefer it if we did not target these high level features at any milestone, since it is possible that extending the Service and Library wizards might cross multiple releases. If you agree with this change, please target this item at the .8 milestone. If you do not agree, please post your comments here. I Brian, I agree this should be set to 0.8 milestone, and separate bugs might need to be created for more detailed tasks. By looking at the description, it seems we are going an approach to add the Database Application support into each wizard. We already have Record wizard which can created Record from database, now service and library wizard are going to be enhanced the same way. There might be some usability issues since the functions are separated. Scenario 1. When creating a service from a DB table, where does the Record come from? Will the service wizard duplicate some of the Record wizard function or actually launches the Record wizard? What if user has already created Record somewhere? Scenario 2. We already have a database app created using the Record Wizard, Service Wizard & Library Wizard. Now a new column is added to the table. How do we update our app to use the new column? Should user run each Wizard again? Tim has talked about the concept of modeling an "Application Design Pattern" with EGL in one of his emails, and said the Data Access Wizard is the perfect place to show how Application models are defined and fit in with data models and how these separate patterns. I'm adding Tim to this bug This work is considered one of the main themes for the .8 release. In response to Comment 5 - regardless of whether we come up with an application type that allows a developer to model a data access app, developers still need the ability to create a conventional EGL service and library to access data in a database. So, I think this application pattern requirement needs to be broken out from this bug and discussed independently. Created attachment 210309 [details]
Prototype code showing possible service and records
I started prototyping what I thought the service might look like (see attached). It's based on the service produced in the RBD Data Access (DAA) wizard, but I tried to come up with a solution for the way we return 'status'. I don't like how the current DAA-produced service forces the developer into passing either an empty object/array or Statusrec on the call statement - this is not logical to me (and will confuse new users). If the developer wants all Employee records (for example), the API should be 'getEmployeeListAll() returns (Employee[])'. Of course, we should also provide an API that returns back status information, since this is important in some situations/apps. The attached code is nowhere near complete, but a starting point. It demonstrates an approach where there are duplicate APIs, one that returns a concrete type (e.g. Employee), another that returns a Results, that includes status and the data being requested. (Fan - this is the same code I sent to you back in December via email) Created attachment 210424 [details]
The Slides and meeting minutes of the requirement & deisgn meeting.
Created attachment 210425 [details]
The Slides and meeting minutes of the requirement & deisgn meeting.
Hi Will and Brian, According to the discussion yesterday, I update the slide and add the Solution/TODO information (in BLUE box) in the document. Would you please review it? Appreciate for all of your help very much! The latest design looks good to me. I agree with trying to re-use as much code as possible from the existing SQL Record Wizard. (In reply to comment #13) > The latest design looks good to me. I agree with trying to re-use as much code > as possible from the existing SQL Record Wizard. Today when we review the design for how to generate the data access code after user selects the table, Tony proposed a good approach to generate the service code. Our original design is that generate the service code from Java object (so-called the Java to EGL code generator). Tony's approach is to use the EGL to EGL generator, it has following steps. 1) Re-use existing code of record wizard to generate the record from table. 2) The EGL record code is compiled to IR model. 3) Read the IR model & generate to the EGL service code. The advantage for the 2nd proposal is that, the code for generating the record to EGL service (the 3rd step) can be re-used if we want to add a wizard template for 'creating service from SQL records'. Also, maybe it will have some benefits when we want to add other record to EGL service wizard (E,g, generate the service for the record generated from XML/JSON etc). Do you have any comments? (In reply to comment #14) > (In reply to comment #13) > > The latest design looks good to me. I agree with trying to re-use as much code > > as possible from the existing SQL Record Wizard. > > Today when we review the design for how to generate the data access code after > user selects the table, Tony proposed a good approach to generate the service > code. > > Our original design is that generate the service code from Java object > (so-called the Java to EGL code generator). > > Tony's approach is to use the EGL to EGL generator, it has following steps. > 1) Re-use existing code of record wizard to generate the record from table. > 2) The EGL record code is compiled to IR model. > 3) Read the IR model & generate to the EGL service code. > > The advantage for the 2nd proposal is that, the code for generating the record > to EGL service (the 3rd step) can be re-used if we want to add a wizard > template for 'creating service from SQL records'. Also, maybe it will have some > benefits when we want to add other record to EGL service wizard (E,g, generate > the service for the record generated from XML/JSON etc). > > Do you have any comments? One another problem is that we don't have the EGL record files generated in the project before finishing the service creation wizard. However, we want to display the code of service in the last page of the wizard. So it will have problem for the 2nd step - we don't have the IR model for EGL records yet, so the EGL service code cannot be generated as well. We need to get the EGL record IR model in the memory, and then generate the service code. So one question for Paul, do we have any methods for passing the string value of EGL file contents, and the returned value is IR model? What details of the record does the SQL service/library code actually need? I would hope the service/library could be as generic as possible (other than function names that match the name of the record, e.g. getEmployee). Is knowledge about the fields of the record needed during creation of the service/library code? (To say it another way, I would think the fully-qualified record part name and the names of the key fields are the only input to the service creation code) The only one place that required information besides record name and id field is
function getEmployeeListWithStatus(listSpec ListSpecification) returns (EmployeeListWithStatus)
...
prepare selectStatement from dataSource
with "SELECT EMPNO, FIRSTNME, MIDINIT, LASTNAME, WORKDEPT, PHONENO, HIREDATE, JOB, EDLEVEL, SEX, BIRTHDATE, SALARY, BONUS, COMM " +
listSpec.fromTablesWhere;
In this sample code, all fields (or table column) is needed.
(In reply to comment #16)
> What details of the record does the SQL service/library code actually need? I
> would hope the service/library could be as generic as possible (other than
> function names that match the name of the record, e.g. getEmployee). Is
> knowledge about the fields of the record needed during creation of the
> service/library code?
>
> (To say it another way, I would think the fully-qualified record part name and
> the names of the key fields are the only input to the service creation code)
Does "select * " + listSpec.fromTablesWhere not work? Hi Will, Another question about the design: If there are 2 tables with the same name in different schema, the generator will generate 2 EGL record with the same record name, then a compile error will be reported. Should we add some restriction to do not allow developer select tables from different schema, or check if there are 2 tables with the same name before going to the preview page? Thanks very much! I believe we decided to put all the functions for get, add, update, etc for multiple tables in the same service/library. If so, I think we should prevent the developer from selecting multiple tables/views with the same name in the wizard (by showing an error on the wizard page and preventing next/finish). I think this scenario is unlikely, so I don't think this approach is overly aggressive. Created attachment 212049 [details]
patch
fixed close |