Changes between Version 1 and Version 2 of FDORfc68
- Timestamp:
- Sep 11, 2013, 5:43:00 AM (11 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
FDORfc68
v1 v2 1 1 ---- 2 = FDO RFC 68 - Title Goes Here =2 = FDO RFC 68 - Allowing PostgreSQL provider to support case insensitive database = 3 3 4 4 This page contains a request for comments document (RFC) for the FDO Open Source project. … … 8 8 9 9 ||RFC Template Version||(1.1)|| 10 ||Submission Date|| (Date/Time submitted)||11 ||Last Modified|| (your name - Month Day, Year)||12 ||Author|| (your name here)||13 ||RFC Status|| (draft, proposed, frozen for vote, adopted, retracted, or rejected)||14 ||Implementation Status|| (pending, under development, completed)||15 ||Proposed Milestone|| (e.g. 1.1, 1.3)||16 ||Assigned PSC guide(s)|| (when determined)||17 ||'''Voting History'''|| (vote date)||18 ||+1|| Bob, Mateusz||19 ||+0|| Frank||20 ||-0|| Orest||21 ||-1|| Greg (troublemaker)||10 ||Submission Date|| September 11, 2013|| 11 ||Last Modified|| Bruno Scott September 11, 2013|| 12 ||Author|| Bruno Scott|| 13 ||RFC Status||draft|| 14 ||Implementation Status||completed|| 15 ||Proposed Milestone||3.9.0.0|| 16 ||Assigned PSC guide(s)|||| 17 ||'''Voting History'''|| || 18 ||+1|| || 19 ||+0|| || 20 ||-0|| || 21 ||-1|| || 22 22 23 23 == Overview == 24 24 25 This section briefly describes the problem set, and the proposed solution in general terms. It should be deliberately short, a couple of sentences or so.25 This RFC is for enhancing the PostgreSQL provider to support case insensitive PostGreSQL database. 26 26 27 27 == Motivation == 28 28 29 This is the most important part of the RFC. It describes the problem domain in detail. Focusing on this will allow reviewers to fully understand why the proposed change is being made, and potentially suggest different/better ways of accomplishing the desired results. The more time we spend on understanding the problem, the better our solution will be.29 Actually all internal SQL statement made by the postgreSQL provider are double quoted, this means that it only support case sensitive database. When you have an existing application that use FDO as a generic database engine , you are forced to change your application to surround all your table name and column name with double quotes ( on native SQL staments ) and to use the same Tble/Column Name case as defined in the database. You have to do this only when dealing with a PostGreSQL database. FDO is a great tool because you can use the same application to support many databases(Oracle, Sqlite, Sqlserver,PostgreSQL...) only by changing the connection string. The purpose of this RFC is to make the provider supporting case insensitive postgreSQL database along with the actual case sensitive behavior. 30 30 31 31 == Proposed Solution == 32 32 33 This is a more detailed description of the actual changes desired. The contents of this section will vary based on the target of the RFC, be it a technical change, website change, or process change. For example, for a technical change, items such as files, XML schema changes, and API chances would be identified. For a process change, the new process would be laid out in detail. For a website change, the files affected would be listed. 33 We propose to add a new optional connection parameter : CaseSensitive 34 {{{ 35 example : dataStore=myDatabase;Service=localhost;Password=mypwd;Username=postgres;CaseSensitive=FALSE 36 }}} 37 If not set: 38 the default behavior is CaseSensitive=TRUE, so there will be no impact on existing application. 39 When case sensitive is set to TRUE: 40 *No double quotes would be added to internal sql satement. 41 *Table creation will be made with lowercase table name and lowercase column name, thus creating a case insensitive table. 34 42 35 43 == Implications == 36 44 37 This section allows discussion of the repercussions of the change, such as whether there will be any breakage in backwards compatibility, if documentation will need to be updated, etc. 45 Find all the places where double quotes are added and modify the code to test the CaseSensitive parameter. 46 Find all the places where schema element (table and column name) are looked up using case sensitive function like wcscmp and modify the code to test the CaseSensitive parameter 38 47 39 48 == Test Plan == 40 49 41 How the proposed change will be tested, if applicable. New unit tests should be detailed here??? 50 Actual unit test should be run as is without the casesensitive parameter 51 It could be usefull to re run the test with the casesensitive parameter set to FALSE 42 52 43 53 == !Funding/Resources == 44 54 45 This section will confirm that the proposed feature has enough support to proceed. This would typically mean that the entity making the changes would put forward the RFC, but a non-developer could act as an RFC author if they are sure they have the funding to cover the change.55 Geomap Infrastruction Solutions to provide resources/funding.
