|
Hi all,
I've recently completed taking all the existing code and existing docs and putting them in an RFC with respect to Zend_Db. It can be located here: http://framework.zend.com/wiki/display/ZFDEV2/RFC+-+Zend+Db I feel like it addressed many concerns, it includes simple usage examples as well as proposed interfaces for various parts of the system. At this point, you may have seen some of the requirements before in some way, but this is the location I'd like to start soliciting feedback if anything needs to change. I'd like to see some discussion about this RFC start happening since I know many of us (including myself :) ) are having lots of one-off conversations about Zend_Db in person, on the mailing list and in IRC. High points: * Adhere to single responsibility, this means more, but smaller objects that are only concerned with a discrete objective/responsibility * Separating out access from platform concerns * A more robust Sql (query) generation component is proposed * Separation between Table Gateway and Row Gateway interfaces * A metadata component is proposed * There is a Rowset component proposed * Cross cutting concerns are addressed via an event system (ideally opt-in) I've removed the active record proposition as I think something like that goes into a separate RFC and should wait until this API is fully decided and fleshed out. I am looking forward to everyone's feedback, and as I get it, I will update the document. Thanks! Ralph Schindler -- ralph.schindler [at] zend.com Software Engineer Zend Framework Team -- List: [hidden email] Info: http://framework.zend.com/archives Unsubscribe: [hidden email] |
|
On Tue, Nov 15, 2011 at 9:19 PM, Ralph Schindler
<[hidden email]>wrote: > Hi all, > > I've recently completed taking all the existing code and existing docs and > putting them in an RFC with respect to Zend_Db. It can be located here: > > http://framework.zend.com/**wiki/display/ZFDEV2/RFC+-+**Zend+Db<http://framework.zend.com/wiki/display/ZFDEV2/RFC+-+Zend+Db> > > I feel like it addressed many concerns, it includes simple usage examples > as well as proposed interfaces for various parts of the system. At this > point, you may have seen some of the requirements before in some way, but > this is the location I'd like to start soliciting feedback if anything > needs to change. > > I'd like to see some discussion about this RFC start happening since I > know many of us (including myself :) ) are having lots of one-off > conversations about Zend_Db in person, on the mailing list and in IRC. [...] I am looking forward to everyone's feedback, and as I get it, I will update > the document. > > Thanks! > Ralph Schindler > Without reading the whole RFC (will do that later), the usage of the namespace Zend\Db for the SQL only databases closes the door to any other database system. Recently the document based and key-value based systems get more and more attention and I'd like to keep the option open to place them under the Zend\Db namespace as well. Is that possible? (so actually it's "just" s/Zend\Db/Zend\Db\Sql/g). -- Jurian Sluiman |
|
In reply to this post by ralphschindler
It looks really good but I have some small questions:
SHOULD support drivers: ext/mysql -> Wasn't it deprecated for PHP 5.4 Will the returned class instance switch on SELECT vs. INSERT/UPDATE queries: $result = $dbAdapter->query('SELECT ...', Adapter\Adapter::QUERY_MODE_EXECUTE); $result = $dbAdapter->query('UPDATE ...', Adapter\Adapter::QUERY_MODE_EXECUTE); -> Or is it possible to implement an "exec" method returning modified rows I don't found information about ZF-870 (test if a transaction is in use) Greetings Marc ----- Original Nachricht ---- Von: Ralph Schindler <[hidden email]> An: [hidden email] Datum: 15.11.2011 21:19 Betreff: [zf-contributors] RFC - Zend Db in ZF2 > Hi all, > > I've recently completed taking all the existing code and existing docs > and putting them in an RFC with respect to Zend_Db. It can be located > here: > > http://framework.zend.com/wiki/display/ZFDEV2/RFC+-+Zend+Db > > I feel like it addressed many concerns, it includes simple usage > examples as well as proposed interfaces for various parts of the system. > At this point, you may have seen some of the requirements before in > some way, but this is the location I'd like to start soliciting feedback > if anything needs to change. > > I'd like to see some discussion about this RFC start happening since I > know many of us (including myself :) ) are having lots of one-off > conversations about Zend_Db in person, on the mailing list and in IRC. > > High points: > * Adhere to single responsibility, this means more, but smaller > objects that are only concerned with a discrete objective/responsibility > * Separating out access from platform concerns > * A more robust Sql (query) generation component is proposed > * Separation between Table Gateway and Row Gateway interfaces > * A metadata component is proposed > * There is a Rowset component proposed > * Cross cutting concerns are addressed via an event system (ideally > opt-in) > > I've removed the active record proposition as I think something like > that goes into a separate RFC and should wait until this API is fully > decided and fleshed out. > > I am looking forward to everyone's feedback, and as I get it, I will > update the document. > > Thanks! > Ralph Schindler > > -- > ralph.schindler [at] zend.com > Software Engineer > Zend Framework Team > > -- > List: [hidden email] > Info: http://framework.zend.com/archives > Unsubscribe: [hidden email] > > > MfG Marc Bennewitz -- List: [hidden email] Info: http://framework.zend.com/archives Unsubscribe: [hidden email] |
|
In reply to this post by Jurian Sluiman-3
On Wed, Nov 16, 2011 at 9:08 AM, Jurian Sluiman <[hidden email]>wrote:
> > Without reading the whole RFC (will do that later), the usage of the > namespace Zend\Db for the SQL only databases closes the door to any other > database system. Recently the document based and key-value based systems > get more and more attention and I'd like to keep the option open to place > them under the Zend\Db namespace as well. Is that possible? (so actually > it's "just" s/Zend\Db/Zend\Db\Sql/g). > NoSQL are also Databases, hence DB. They can be record oriented, or document oriented or spatial, tree, or genetic or whatever else. Zend\Db\Sql is obviously for SQL. I see no problem with building Zend\Db\OQL or Zend\Db\UnQL<http://www.arnnet.com.au/article/395469/couchbase_sqlite_launch_unified_nosql_query_language> (specs <http://www.unqlspec.org/display/UnQL/Home>) Ralph: I've skimmed through RFC and there was no word on non-relational stuff there, but it might be a good moment to architect Zend\Db so it would be trivial to add those. A resultset, gateway, or AR, these are quite universal and can easily be interfaced to document-based or record-based systems. Mention of DML in RFC makes me think that RFC is SQL-biased. I'd even say, there is no place for separate Zend\NoSql (Zend\NoDb? :-) ) component and it should live inside Db. It would also make for some interesting use cases (like all-time-favorite MySQL -> couchDB migration, just by swapping adapters). A. -- __ /.)\ +48 695 600 936 \(./ [hidden email] |
|
Administrator
|
In reply to this post by Marc Bennewitz (private)
-- Marc Bennewitz <[hidden email]> wrote
(on Wednesday, 16 November 2011, 10:25 AM +0100): > It looks really good but I have some small questions: > > SHOULD support drivers: ext/mysql > -> Wasn't it deprecated for PHP 5.4 Only via documentation; it's still present and raises no E_DEPRECATED warnings. Also, we're still targeting PHP 5.3 at this time for v2, which means it's still viable. The interesting bit, however, is that an ext/mysql adapter would simply use the same dialect as for ext/mysqli or pdo/mysql. So the actual maintenance is wrapped in those two items. > Will the returned class instance switch on SELECT vs. INSERT/UPDATE queries: > $result = $dbAdapter->query('SELECT ...', Adapter\Adapter::QUERY_MODE_EXECUTE); > $result = $dbAdapter->query('UPDATE ...', Adapter\Adapter::QUERY_MODE_EXECUTE); > -> Or is it possible to implement an "exec" method returning modified rows > > I don't found information about ZF-870 > (test if a transaction is in use) I'll defer to Ralph on these questions. > ----- Original Nachricht ---- > Von: Ralph Schindler <[hidden email]> > An: [hidden email] > Datum: 15.11.2011 21:19 > Betreff: [zf-contributors] RFC - Zend Db in ZF2 > > > Hi all, > > > > I've recently completed taking all the existing code and existing docs > > and putting them in an RFC with respect to Zend_Db. It can be located > > here: > > > > http://framework.zend.com/wiki/display/ZFDEV2/RFC+-+Zend+Db > > > > I feel like it addressed many concerns, it includes simple usage > > examples as well as proposed interfaces for various parts of the system. > > At this point, you may have seen some of the requirements before in > > some way, but this is the location I'd like to start soliciting feedback > > if anything needs to change. > > > > I'd like to see some discussion about this RFC start happening since I > > know many of us (including myself :) ) are having lots of one-off > > conversations about Zend_Db in person, on the mailing list and in IRC. > > > > High points: > > * Adhere to single responsibility, this means more, but smaller > > objects that are only concerned with a discrete objective/responsibility > > * Separating out access from platform concerns > > * A more robust Sql (query) generation component is proposed > > * Separation between Table Gateway and Row Gateway interfaces > > * A metadata component is proposed > > * There is a Rowset component proposed > > * Cross cutting concerns are addressed via an event system (ideally > > opt-in) > > > > I've removed the active record proposition as I think something like > > that goes into a separate RFC and should wait until this API is fully > > decided and fleshed out. > > > > I am looking forward to everyone's feedback, and as I get it, I will > > update the document. > > > > Thanks! > > Ralph Schindler > > > > -- > > ralph.schindler [at] zend.com > > Software Engineer > > Zend Framework Team > > > > -- > > List: [hidden email] > > Info: http://framework.zend.com/archives > > Unsubscribe: [hidden email] > > > > > > > > MfG > > Marc Bennewitz > > -- > List: [hidden email] > Info: http://framework.zend.com/archives > Unsubscribe: [hidden email] > > -- Matthew Weier O'Phinney Project Lead | [hidden email] Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc -- List: [hidden email] Info: http://framework.zend.com/archives Unsubscribe: [hidden email] |
|
Administrator
|
In reply to this post by Jurian Sluiman-3
-- Jurian Sluiman <[hidden email]> wrote
(on Wednesday, 16 November 2011, 09:08 AM +0100): > On Tue, Nov 15, 2011 at 9:19 PM, Ralph Schindler > <[hidden email]>wrote: > > I've recently completed taking all the existing code and existing docs and > > putting them in an RFC with respect to Zend_Db. It can be located here: > > > > http://framework.zend.com/**wiki/display/ZFDEV2/RFC+-+**Zend+Db<http://framework.zend.com/wiki/display/ZFDEV2/RFC+-+Zend+Db> > > > > I feel like it addressed many concerns, it includes simple usage examples > > as well as proposed interfaces for various parts of the system. At this > > point, you may have seen some of the requirements before in some way, but > > this is the location I'd like to start soliciting feedback if anything > > needs to change. > > > > I'd like to see some discussion about this RFC start happening since I > > know many of us (including myself :) ) are having lots of one-off > > conversations about Zend_Db in person, on the mailing list and in IRC. > > > > [...] > > > > I am looking forward to everyone's feedback, and as I get it, I will update > > the document. > > > > Thanks! > > Ralph Schindler > > > > Without reading the whole RFC (will do that later), the usage of the > namespace Zend\Db for the SQL only databases closes the door to any other > database system. Recently the document based and key-value based systems > get more and more attention and I'd like to keep the option open to place > them under the Zend\Db namespace as well. Is that possible? (so actually > it's "just" s/Zend\Db/Zend\Db\Sql/g). "DB" is commonly used to refer to RDBM systems, and the abstraction provided in Zend\Db is around RDBMS systems. NoSQL systems are much tougher to abstract, and while many are referred to as "database" systems, they are not RDBM systems. While we _could_ switch to a different namespace, such as "Zend\Rdbms" or "Zend\Sql" or "Zend\Db\Rdbms" or "Zend\Db\Sql", the other thing to consider is migration and education. Most folks coming from ZF1 will likely get confused and wonder where "Zend\Db" went, and since it's not uncommon to equate "db" with "rdbms", even newcomers would likely be confused. (And pushing RDBMS into a subnamespace would make for a really ungainly hierarchy.) Finally, I'm unsure how much effort we really want to put into NoSQL abstraction, if any. The fact of the matter is that the only real part you can abstract is the CRUD aspects -- and even those are somewhat difficult, as the notion of what defines a key is often widely variable between systems. As for grabbing many records at once, the APIs and methodologies are so widely divergent that abstraction is impossible. As such, I'm not sure having "Zend\Db" open for anything other than RDBM systems makes any sense. -- Matthew Weier O'Phinney Project Lead | [hidden email] Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc -- List: [hidden email] Info: http://framework.zend.com/archives Unsubscribe: [hidden email] |
|
In reply to this post by Jurian Sluiman-3
Hey Jurian,
I think since we're moving to a package oriented structure, it might make sense to keep these two things separate. While they both are databases in the most global sense of the word, they are not interchangeable technologies. Zend_Db has traditionally (in zf1) meant "RDBMS". I think that makes a strong case to keep that as such. Further, it's hard to look at the APIs for the NoSQL databases and find a common API or feature-set they might share. Each has its own strengths and weaknesses, and that is reflected in the native php extension, the actual nosql server in question, and then in the way in which a developer is suppose to interact with it (do you query with json structs? etc). Relations databases, on the other hand, have ANSI sql to fall back on, even if they do go above and beyond that when it comes to the finer grained featuresets. All that said, we're in a place where we have prior expectations and some reasoning, so to change this, we'd have to have a majority consensus on something like this. -ralph On 11/16/11 2:08 AM, Jurian Sluiman wrote: > On Tue, Nov 15, 2011 at 9:19 PM, Ralph Schindler > <[hidden email] <mailto:[hidden email]>> wrote: > > Hi all, > > I've recently completed taking all the existing code and existing > docs and putting them in an RFC with respect to Zend_Db. It can be > located here: > > http://framework.zend.com/__wiki/display/ZFDEV2/RFC+-+__Zend+Db > <http://framework.zend.com/wiki/display/ZFDEV2/RFC+-+Zend+Db> > > I feel like it addressed many concerns, it includes simple usage > examples as well as proposed interfaces for various parts of the > system. At this point, you may have seen some of the requirements > before in some way, but this is the location I'd like to start > soliciting feedback if anything needs to change. > > I'd like to see some discussion about this RFC start happening since > I know many of us (including myself :) ) are having lots of one-off > conversations about Zend_Db in person, on the mailing list and in IRC. > > [...] > > I am looking forward to everyone's feedback, and as I get it, I will > update the document. > > Thanks! > Ralph Schindler > > > Without reading the whole RFC (will do that later), the usage of the > namespace Zend\Db for the SQL only databases closes the door to any > other database system. Recently the document based and key-value based > systems get more and more attention and I'd like to keep the option open > to place them under the Zend\Db namespace as well. Is that possible? (so > actually it's "just" s/Zend\Db/Zend\Db\Sql/g). > > -- > Jurian Sluiman -- List: [hidden email] Info: http://framework.zend.com/archives Unsubscribe: [hidden email] |
|
In reply to this post by Marc Bennewitz (private)
On 11/16/11 3:25 AM, Marc Bennewitz wrote: > It looks really good but I have some small questions: > > SHOULD support drivers: ext/mysql > -> Wasn't it deprecated for PHP 5.4 Try as we might, I don't see ext/mysql going away. I don't know what the status is, but projects like wordpress and drupal still let you leverage ext/mysql (wordpress by default tmk). Sometimes, you want a 3rd party library (like Zend\Db) available to you when you're writing wordpress plugins. I've been in that situation, and in that situation, I simply wanted to reuse the open/existing connection. If writing an execute only wrapper for ext/mysql lets me be able to use higher order API's and solutions like TableGateway and RowGateway, it sounds like a win-win to me. -- List: [hidden email] Info: http://framework.zend.com/archives Unsubscribe: [hidden email] |
|
Administrator
|
In reply to this post by Artur Bodera
-- Artur Bodera <[hidden email]> wrote
(on Wednesday, 16 November 2011, 11:38 AM +0100): > On Wed, Nov 16, 2011 at 9:08 AM, Jurian Sluiman <[hidden email]>wrote: > > > > > Without reading the whole RFC (will do that later), the usage of the > > namespace Zend\Db for the SQL only databases closes the door to any other > > database system. Recently the document based and key-value based systems > > get more and more attention and I'd like to keep the option open to place > > them under the Zend\Db namespace as well. Is that possible? (so actually > > it's "just" s/Zend\Db/Zend\Db\Sql/g). > > > > NoSQL are also Databases, hence DB. They can be record oriented, or > document oriented or spatial, tree, or genetic or whatever else. > > Zend\Db\Sql is obviously for SQL. > > I see no problem with building Zend\Db\OQL or > Zend\Db\UnQL<http://www.arnnet.com.au/article/395469/couchbase_sqlite_launch_unified_nosql_query_language> > (specs <http://www.unqlspec.org/display/UnQL/Home>) I disagree, and have noted this in a previous response. UnQL is not widely adopted, and, to be honest, looks like it's going to face a rather lengthy uphill battle to get either adoption or standardization. > Ralph: > I've skimmed through RFC and there was no word on non-relational stuff > there, but it might be a good moment to architect Zend\Db so it would > be trivial to add those. A resultset, gateway, or AR, these are quite > universal and can easily be interfaced to document-based or > record-based systems. Resultsets are collections, and yes, those can be standardized. However, how you _get_ the data for them is very, very different when it comes to NoSQL solutions. Some require extensions, some have query apis/languages, others use map/reduce -- and each of these pose their own challenges when abstracting collections. That said, I'm not against it -- but I'm not sure it belongs in Zend\Db, either; collections are DB-agnostic, tbh. Gateway is a generic pattern, also not necessarily specific to RDBMS. However, Table Data Gateway and Row Data Gateway _are_ specific to RDBMS. Finally, ActiveRecord is typically associated with RDBMS, but is really simply an abstraction of CRUD operations... but also over retrieving result _sets_ -- and the latter aspect of it typically binds it to RDBMS systems since they provide a known methodology for retrieval (SQL). As I said in a previous post on this thread, it actually is NON-TRIVIAL to add NoSQL, because the amount of functionality that can be abstracted is very narrow. > Mention of DML in RFC makes me think that RFC is SQL-biased. yes, it is. > I'd even say, there is no place for separate Zend\NoSql (Zend\NoDb? > :-) ) component and it should live inside Db. It would also make for > some interesting use cases (like all-time-favorite MySQL -> couchDB > migration, just by swapping adapters). I disagree, and I've stated my reasons here and elsewhere. There's a reason they're called "NoSQL" -- it's because they are not using a "structured query language". Even with the many varieties of SQL, it's still fairly easy to write an abstraction on top of them -- particularly with the concept of dialects as Ralph has proposed. With NoSQL, however, you end up having to drop into vendor-specific approaches immediately whenever you need to query for anything beyond a single record -- and even _that_ can vary between vendors (do you have to specify the field indicating the identifier? and how do you specify it -- as a JSON object, a string, a custom object? etc.) While a "Zend\NoSql" namespace _might_ make sense, there are many varieties of NoSQL solutions, and each have specific strengths (and weaknesses). There are document databases, key/value databases, column-oriented databases, the "big table" databases, geospatial databases, etc. To be honest, it would probably make the most sense to group these under separate top-level namespaces -- Zend\DocumentDb or Zend\DocDb, Zend\GeospatialDb, etc. To clarify: I _LOVE_ NoSQL solutions, and in fact have my blog running on MongoDB. But I've also taken the time to play with and learn about a variety of NoSQL solutions, and really don't see any real ways we can have the same level of abstraction for them as we have for RDBM systems. I also think it's worth _attempting_ -- but not. right. now. Ralph's proposal is targeting the existing Zend\Db from ZF1 and proposing an architectural overhaul of that DBAL. Let's discuss _that_, and move forward, please. -- Matthew Weier O'Phinney Project Lead | [hidden email] Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc -- List: [hidden email] Info: http://framework.zend.com/archives Unsubscribe: [hidden email] |
|
On Wed, Nov 16, 2011 at 5:47 PM, Matthew Weier O'Phinney
<[hidden email]>wrote: > While a "Zend\NoSql" namespace _might_ make sense, there are many > varieties of NoSQL solutions, and each have specific strengths (and > weaknesses). There are document databases, key/value databases, > column-oriented databases, the "big table" databases, geospatial > databases, etc. To be honest, it would probably make the most sense to > group these under separate top-level namespaces -- Zend\DocumentDb or > Zend\DocDb, Zend\GeospatialDb, etc. > > > not use the term NoSQL as a namespace. The namespace should be referring to what it *is*, not what it is *not*. http://arr.gr/blog/2011/10/why-i-dont-like-the-term-nosql/ ;) Shahar. |
|
In reply to this post by ralphschindler
Will profiling be covered by the Zend\Db component or will it be left to concrete applications via the plugins suggested in RFC?
MUST support plug-ablity via callbacks at various times during runtime:
On Wed, Nov 16, 2011 at 4:19 AM, Ralph Schindler <[hidden email]> wrote: Hi all, Taiwen Jiang (aka D.J.) Build Xoops Engine
web and mobile application platform CTO for EEFOCUS.com Leading social platform for electronics professionals |
|
Bump up.
Sorry to bother but I would like to have some hints either there would be profiler in Zend\Db or I have to build one. On Mon, May 14, 2012 at 7:13 PM, D. J. <[hidden email]> wrote: Will profiling be covered by the Zend\Db component or will it be left to concrete applications via the plugins suggested in RFC? Taiwen Jiang (aka D.J.) Build Xoops Engine
web and mobile application platform CTO for EEFOCUS.com Leading social platform for electronics professionals |
| Powered by Nabble | Edit this page |
