Thread: [Phpslash-trackers] [ phpslash-Feature Requests-524852 ] DB Abstraction
Brought to you by:
joestewart,
nhruby
From: <no...@so...> - 2002-03-02 17:14:26
|
Feature Requests item #524852, was opened at 2002-03-02 12:14 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=360566&aid=524852&group_id=10566 Category: None Group: None Status: Open Priority: 5 Submitted By: nathan hruby (nhruby) Assigned to: Nobody/Anonymous (nobody) Summary: DB Abstraction Initial Comment: While MySQL is a very nice and fast db not everyone in the world uses it (yet). It would be a nice thing to support multiple databases through an abstraction layer that removes all db work from the various classes and centralizes it into a sigle class. this would allow a module to simple call: $db->store('datatype', 'data'); $db->get('datatype', 'options') This is different from simple PEAR or PHPLIB db abstraction at the db interface level, as we're abstracting all of our application level db interaction. This is a very large and time intensive project that requires knowledge of multiple databses and a great deal of planning to make a fast, useable and scaleable API. This is not something to be undertaken in an afternoon. In terms of scheduling there are two schools of thought: - Incorperate it now fo rlots of testing and less porting work later. - Do this last once all the db queires, schems and such take place and we're not trying to abstract a moving target. My personal feeling is that there is a great deal of work to do in the phpslash feature set and some confusion about where is is going. Until these things settle down and a concrete feature set is devloped with a fintie direction, such a large and invaseive task should not be undertaken ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=360566&aid=524852&group_id=10566 |
From: SourceForge.net <no...@so...> - 2004-10-23 14:16:09
|
Feature Requests item #524852, was opened at 2002-03-02 11:14 Message generated for change (Settings changed) made by joestewart You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=360566&aid=524852&group_id=10566 >Category: database >Group: m9 Status: Open Priority: 5 Submitted By: nathan hruby (nhruby) Assigned to: Nobody/Anonymous (nobody) Summary: DB Abstraction Initial Comment: While MySQL is a very nice and fast db not everyone in the world uses it (yet). It would be a nice thing to support multiple databases through an abstraction layer that removes all db work from the various classes and centralizes it into a sigle class. this would allow a module to simple call: $db->store('datatype', 'data'); $db->get('datatype', 'options') This is different from simple PEAR or PHPLIB db abstraction at the db interface level, as we're abstracting all of our application level db interaction. This is a very large and time intensive project that requires knowledge of multiple databses and a great deal of planning to make a fast, useable and scaleable API. This is not something to be undertaken in an afternoon. In terms of scheduling there are two schools of thought: - Incorperate it now fo rlots of testing and less porting work later. - Do this last once all the db queires, schems and such take place and we're not trying to abstract a moving target. My personal feeling is that there is a great deal of work to do in the phpslash feature set and some confusion about where is is going. Until these things settle down and a concrete feature set is devloped with a fintie direction, such a large and invaseive task should not be undertaken ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=360566&aid=524852&group_id=10566 |