Re: Convention for case of SQL objects
First choice is UPPER_CASE second choice is lower_case -Brian On Feb 14, 2005, at 6:42 PM, Matthew T. Adams wrote: I like UPPER_CASE... -Original Message- From: Michelle Caisse [mailto:[EMAIL PROTECTED] Sent: Monday, February 14, 2005 3:41 PM To: jdo-dev@db.apache.org Subject: Convention for case of SQL objects Hi, all, What capitalization convention would you like to see used for names of tables, views, columns, indexes and constraints in SQL commands used in the TCK? Choices are lower_case, UPPER_CASE, Initial_upper_case or CamelCase. Practice seems to vary from author to author. -- Michelle
Re: Fwd: Convention for case of SQL objects
On Tuesday 15 February 2005 07:49, Craig Russell wrote: > Please reply to jdo-dev alias as well as jdo-experts alias. > > This is not a super important issue but it's very timely. :o) IMHO, I think the UPPERCASE that is still preferred by many DB admins are a relic from COBOL days, and that the CamelCase is both easier to read. But since Tables maps roughly with classes and columns roughly to members, wouldn't it make sense to preserve case at all times when automated and 'use' same case when manually mapped? I also think this is a non-issue in that if there is already something in place, then use it. Don't spend time on a change. Cheers Niclas
RE: Convention for case of SQL objects
Since this is intended to test the implementation, why not use all of them? Erik Bengtson -Original Message- From: Michelle Caisse [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 15, 2005 12:41 AM To: jdo-dev@db.apache.org Subject: Convention for case of SQL objects Hi, all, What capitalization convention would you like to see used for names of tables, views, columns, indexes and constraints in SQL commands used in the TCK? Choices are lower_case, UPPER_CASE, Initial_upper_case or CamelCase. Practice seems to vary from author to author. -- Michelle
Re: Meeting 11-Feb-2005
Hi Michelle, My notes say that we decided ultimately to leave Person as concrete and to map all the classes in that hierarchy to a Person table. yes, this is what I recall, too. - Person is concrete - Employee is abstract - FullTimeEmployee and PartTimeEmployee are both concrete All of them are mapped to a single table. Regards Michael -- Michelle Michael Bouschen wrote: Hi Craig, we also discussed that classes Insurance and Employee of the TCK company model should be abstract. I checked the current implementation: - Insurance is abstract already. - I will make Employee abstract which requires changing three TCK test cases. Today they create Employee instances and I will change this to FullTimeEmployee. Regards Michael Attendees: Craig Russell, Michael Bouschen, Michelle Caisse Discussed mapping Company. The normalized schema has one column in the Insurance table with a foreign key (not unique) to Employee table. The object model has a single field in the Insurance class that references the Employee class. The Employee class has two fields: one for each of the subclasses in Insurance. Question is whether we can map this using the standard mapping in chapter 18. Maven build-site should work for the latest maven repository that can be downloaded from the SubversionRepository wiki page. Updates to chapter 14 assertions for new query: Michelle will send latest chapter 14 to Michael who will add assertions for new APIs and add them to the spreadsheet. Michelle will then update the Frame document with the new assertions. Need to look for new JDO 2.0 assertions in chapters 9, 11, 12, and 15. The spreadsheet will have the sheets renamed to reflect the chapter subject not its number, because some chapter numbers changed from JDO 1 to JDO 2. Michael created a new wiki page for query testing. Discussed capitalization conventions for database schema used for the TCK. Craig will ask the experts for their opinions. The question is whether to use lower_case, UPPER_CASE, or CamelCase for table, column, index, and constraint names. We have not been able to subscribe to individual wiki pages. No one who will talk to us seems to know how the subscriptions are supposed to work. Low priority, just a question. Subscribing to [EMAIL PROTECTED] seems to work for all pages, as a workaround. To get more community involvement in the Apache JDO project, we might automatically subscribe everyone on the jdo-experts alias to jdo-dev alias. We should start to use the jdo-dev alias for all dev business here. Craig Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! -- Michael Bouschen[EMAIL PROTECTED] Engineering GmbH mailto:[EMAIL PROTECTED]http://www.tech.spree.de/ Tel.:++49/30/235 520-33 Buelowstr. 66 Fax.:++49/30/2175 2012 D-10783 Berlin
Assertion numbers in renumbered JDO spec chapters
Hi Craig, hi Michelle, some chapters of the JDO spec are renumbered from 1.0 to 2.0: ChapterJDO 1.0 JDO 2.0 Extent15 19 JDO Reference Enhancer20 21 Interface StateManager21 22 JDOPermission 22 23 I noticed from version 2005-01-14 of the JDO 2.0 spec on the assertions have been renumbered to follow the new chapter numbers, e.g. all the extent assertion are renumbered from A15.x to A19.x. Is this on purpose? If yes, we need to adapt the spreadsheet JdoTckAssertionsTable.sxc and the TCK test classes. We would need to include the old and the new assertion number into the test classes, because we want to use the existing test cases for JDO 1.0 and JDO 2.0. What do you think? Regards Michael -- Michael Bouschen[EMAIL PROTECTED] Engineering GmbH mailto:[EMAIL PROTECTED]http://www.tech.spree.de/ Tel.:++49/30/235 520-33 Buelowstr. 66 Fax.:++49/30/2175 2012 D-10783 Berlin
Re: Assertion numbers in renumbered JDO spec chapters
Yes, that does need to be done. I can do that when I have my turn at the spreadsheet. -- Michelle Michael Bouschen wrote: Hi Craig, hi Michelle, some chapters of the JDO spec are renumbered from 1.0 to 2.0: ChapterJDO 1.0 JDO 2.0 Extent15 19 JDO Reference Enhancer20 21 Interface StateManager21 22 JDOPermission 22 23 I noticed from version 2005-01-14 of the JDO 2.0 spec on the assertions have been renumbered to follow the new chapter numbers, e.g. all the extent assertion are renumbered from A15.x to A19.x. Is this on purpose? If yes, we need to adapt the spreadsheet JdoTckAssertionsTable.sxc and the TCK test classes. We would need to include the old and the new assertion number into the test classes, because we want to use the existing test cases for JDO 1.0 and JDO 2.0. What do you think? Regards Michael
Re: Assertion numbers in renumbered JDO spec chapters
Hi Michelle, I thought about this again and meanwhile I'm not sure whether we should do the renumbering of the assertions. It is a lot of work changing the spreadsheet and the corresponding TCK test classes. But what concerns me more is that all the TCK test cases we have today are valid JDO 1 and JDO 2 tests. For JDO 1 they refer to an annotated spec that uses the old numbering. This means we would have to maintain both the old and the new numbers in the test cases. So I propose to keep the old numbers, even if they do not match the chapter numbers of the new spec. What do you think? Regards Michael Yes, that does need to be done. I can do that when I have my turn at the spreadsheet. -- Michelle Michael Bouschen wrote: Hi Craig, hi Michelle, some chapters of the JDO spec are renumbered from 1.0 to 2.0: ChapterJDO 1.0 JDO 2.0 Extent15 19 JDO Reference Enhancer20 21 Interface StateManager21 22 JDOPermission 22 23 I noticed from version 2005-01-14 of the JDO 2.0 spec on the assertions have been renumbered to follow the new chapter numbers, e.g. all the extent assertion are renumbered from A15.x to A19.x. Is this on purpose? If yes, we need to adapt the spreadsheet JdoTckAssertionsTable.sxc and the TCK test classes. We would need to include the old and the new assertion number into the test classes, because we want to use the existing test cases for JDO 1.0 and JDO 2.0. What do you think? Regards Michael -- Michael Bouschen[EMAIL PROTECTED] Engineering GmbH mailto:[EMAIL PROTECTED]http://www.tech.spree.de/ Tel.:++49/30/235 520-33 Buelowstr. 66 Fax.:++49/30/2175 2012 D-10783 Berlin
Re: Apache development project
Javadogs, So when I tried to subscribe [EMAIL PROTECTED] to jdo-dev@db.apache.org, I realized I don't know how to do it. The subscribe message takes the "from" email address. And I don't know how to fake this. Can anyone help? Craig On Feb 11, 2005, at 1:10 PM, Geoff hendrey wrote: Put us all on via [EMAIL PROTECTED] I think it will generate useful dialog. -geoff --- Craig Russell <[EMAIL PROTECTED]> wrote: Javadogs, We're starting to crank up the Apache TCK development, and some of the info we're discussing should be of interest to the jdo expert group (especially those who have products that need to be compliant with the TCK). You can subscribe individually by following the instructions at http://wiki.apache.org/jdo/MailLists. The list for developers (including api, tck, and ri) is the jdo-dev alias. Alternatively, I could put this alias ([EMAIL PROTECTED]) directly on the jdo-dev alias. Craig Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! ATTACHMENT part 2 application/pkcs7-signature name=smime.p7s __ Do you Yahoo!? Yahoo! Mail - now with 250MB free storage. Learn more. http://info.mail.yahoo.com/mail_250 Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Re: Fwd: Convention for case of SQL objects
The conventions which I'm used to here in London are: table names: capitals with _ separator column names: lowercase with _ separator e.g. EMPLOYEE_PAYROLL.employee_id On Mon Feb 14 20:37:40 PST 2005, Niclas Hedhman <[EMAIL PROTECTED]> wrote: On Tuesday 15 February 2005 07:49, Craig Russell wrote: Please reply to jdo-dev alias as well as jdo-experts alias. This is not a super important issue but it's very timely. :o) IMHO, I think the UPPERCASE that is still preferred by many DB admins are a relic from COBOL days, and that the CamelCase is both easier to read. But since Tables maps roughly with classes and columns roughly to members, wouldn't it make sense to preserve case at all times when automated and 'use' same case when manually mapped? I also think this is a non-issue in that if there is already something in place, then use it. Don't spend time on a change. Cheers Niclas
Re: Assertion numbers in renumbered JDO spec chapters
I'm fine with either approach. I think you're right about the problem with the JDO1 spec, so let's change the numbers back in the 2.0 spec. -- Michelle Michael Bouschen wrote: Hi Michelle, I thought about this again and meanwhile I'm not sure whether we should do the renumbering of the assertions. It is a lot of work changing the spreadsheet and the corresponding TCK test classes. But what concerns me more is that all the TCK test cases we have today are valid JDO 1 and JDO 2 tests. For JDO 1 they refer to an annotated spec that uses the old numbering. This means we would have to maintain both the old and the new numbers in the test cases. So I propose to keep the old numbers, even if they do not match the chapter numbers of the new spec. What do you think? Regards Michael Yes, that does need to be done. I can do that when I have my turn at the spreadsheet. -- Michelle Michael Bouschen wrote: Hi Craig, hi Michelle, some chapters of the JDO spec are renumbered from 1.0 to 2.0: ChapterJDO 1.0 JDO 2.0 Extent15 19 JDO Reference Enhancer20 21 Interface StateManager21 22 JDOPermission 22 23 I noticed from version 2005-01-14 of the JDO 2.0 spec on the assertions have been renumbered to follow the new chapter numbers, e.g. all the extent assertion are renumbered from A15.x to A19.x. Is this on purpose? If yes, we need to adapt the spreadsheet JdoTckAssertionsTable.sxc and the TCK test classes. We would need to include the old and the new assertion number into the test classes, because we want to use the existing test cases for JDO 1.0 and JDO 2.0. What do you think? Regards Michael
