Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
#1 2009-11-09 21:40:18
- Mary
- Sock Enthusiast
- Registered: 2004-06-27
- Posts: 6,236
An idea for Txp 5, regarding db abstraction and more
Txp could make use of Doctrine (LGPL license):
Doctrine is an object relational mapper (ORM) for PHP 5.2.3+ that sits on top of a powerful database abstraction layer (DBAL). One of its key features is the option to write database queries in a proprietary object oriented SQL dialect called Doctrine Query Language (DQL), inspired by Hibernates HQL. This provides developers with a powerful alternative to SQL that maintains flexibility without requiring unnecessary code duplication.
For the abstraction bit, it’s written on top of PDO, and then extends it.
What’s especially nice about it is the ORM part. It has Behaviours, and there are several very useful ones included in the core that Txp could use.
The downside is that it is a library, and so it would add to Txp’s footprint, both in terms of filesize and memory (though there are methods for improving performance).
The plus side is that it would quickly and significantly help make Txp work for DBMS other than MySQL, streamline Txp’s core code (that interacts with the db, of course), make writing future code faster/simpler, and provide a more framework-like ability for extending Txp.
If it’s decided that using something like Doctrine is too much, then PDO by itself should definitely be considered.
Offline
Re: An idea for Txp 5, regarding db abstraction and more
Any clues on how Doctrine stacks up against Propel (which I have learned to use [and hate] for the sake of a Symfony-based app)?
Offline
#3 2009-11-10 18:55:04
- Mary
- Sock Enthusiast
- Registered: 2004-06-27
- Posts: 6,236
Re: An idea for Txp 5, regarding db abstraction and more
I believe they are very similar in features.
There’s a comment on the Symnfony wiki:
Propel is faster. Although, for complex operations, Propel is notorious for using more queries than Doctrine, so Doctrine comes out on top. It comes down to what you’re doing with it as to which is “right” for your project.
I don’t know whether that is (still) accurate or not, as there’s no data included. When I searched to find some benchmarks, there wasn’t much to find and it was based on much older versions of both.
I personally liked Doctrine’s syntax much better, and it appeared to be simpler to configure when I was looking at the two of them (I also discovered them via Symfony).
Are there any Doctrine and Propel experts in the house?
Offline
Re: An idea for Txp 5, regarding db abstraction and more
Hm,
I don’t know much about MySQL – it’s not my thing – and never heart of these mappers, which is my fault too. But I must say, I’m not really a fan of OO frameworks and setting an abstraction layer over an abstraction layer.
OO Frameworks are made for rapid development and for supporting things you never thought of – but they are not made for scalabilty.
So I think it’s more a general questions:
It’s worth to give up the lightweight/scalabilty, which is a main attribute of Textpattern, for new features?
I myself would negate this question. A developer with Textpattern insides maybe would affirm this question.
Digital nomad, sailing the world on a sailboat: 32fthome.com
Offline
#5 2009-11-21 01:21:34
- Mary
- Sock Enthusiast
- Registered: 2004-06-27
- Posts: 6,236
Re: An idea for Txp 5, regarding db abstraction and more
Tommy,
First, this is an ORM, not a framework. I used the phrase “framework-like ability” as a very rough description, and it is limited to when working with the database. At the moment we’re already using a certain amount of abstraction in Txp, but it’s very limited and not presently extendable to other database management systems.
It’s also not abstraction over abstraction layer. It uses PDO, which is a core PHP5 extension. If you read the PDO intro, it says,
PDO provides a data-access abstraction layer, which means that, regardless of which database you’re using, you use the same functions to issue queries and fetch data. PDO does not provide a database abstraction; it doesn’t rewrite SQL or emulate missing features.
Doctrine uses PDO and adds to it where PDO ends, which makes the first layer of abstraction (which is about being as database agnostic as possible).
Doctrine also contains an object relational mapper. This allows you to talk to the database as if it were a PHP class object. If you know what Ruby on Rails’ ActiveRecord is, then you know what an ORM is.
As a quick example, imagine if you could create a new article in Txp by doing:
$article = new Article();
$article['Body'] = 'This is the article body';
$article['Body_html'] = $textile->TextileThis($article['Body']);
$article->save();
And this would work regardless of whether you were using MySQL, PostGreSQL, Sqlite…
You asked what the main attribute would be.
I would argue that being light-weight is only one of Txp’s attributes, not the main one (and even with the added “weight” of Doctrine, it still wouldn’t be the biggest monster out there). Quite a lot of people consider Txp’s tag system to be another of it’s major strengths, or that the admin interface is simple to use.
We’d gain portability (we don’t have this at all at present, and what good is Txp’s light weight if you only have SQLite available to you?) and more extensibility (which is helpful to the core and plugin devs alike).
Offline
Re: An idea for Txp 5, regarding db abstraction and more
I’m sort of jumping in at the deep end here as I really have no experience with this application and don’t do much messing with the database anyway other than the simplest of tasks. I’m wondering how much extra weight this would add. TXP is very light-weight so if we aren’t talking of a particularly large overhead I would think the added advantage of portability would outweigh the larger footprint. Naturally I have absolutely no idea what kind of work it would entail to include something like this.
Stuart
In a Time of Universal Deceit
Telling the Truth is Revolutionary.
Offline
Re: An idea for Txp 5, regarding db abstraction and more
Mary wrote:
We’d gain portability
Nice. From your experiences: Would this imply that we’d need to test across RDBMS platforms, or is the abstraction strong enough to assume that a successful test on, say, MySQL covers all our bases?
Offline
Re: An idea for Txp 5, regarding db abstraction and more
Hi Mary,
ah ok. So I misunterstood you an Doctrine. I think I will a deeper reading on the Doctrine docs.
ActiveRecords are known to me. I had to work with CakePHP two years ago and Cake was trying to simulate the ActiveRecords from RoR.
Digital nomad, sailing the world on a sailboat: 32fthome.com
Offline
#9 2009-11-22 09:37:07
- tennapel
- Member
- Registered: 2009-05-31
- Posts: 62
Re: An idea for Txp 5, regarding db abstraction and more
There are many other frameworks out there, like ZEND and ADODB, both give the flexibility to put PHP applications on top of databases from different vendors. (as long as you use ANSI compatible SQL statements of course).
The question is: does Textpattern really need it? If there is something to investigate, I wonder if Textpattern isn’t better off by investigating developments like CouchDB from Apache, which is a storage layer (a database, but not a RDBMS) especially useful for apps like Textpattern with high performance.
But all in all, MySQL is the most used database in hosting land, it’s fast enough already for most textpattern sites and adding another abstraction layer is always at the cost of some performance and increased complexity, since you have to set-up (or rework) your app in a more abstract framework to maintain future compatibility.
Offline
#10 2009-11-25 09:35:44
- Mary
- Sock Enthusiast
- Registered: 2004-06-27
- Posts: 6,236
Re: An idea for Txp 5, regarding db abstraction and more
Robert: It implies that we’d be the vast majority of the way there, and could make it a kind of extensible thing: MySQL by default (tested and supported by the developers) and folks interested in bringing it the rest of the way would be able to without major rewrites of core code. That’s partly because Doctrine uses PDO (and again, if Doctrine is considered too much, I would highly advocate we still swap to use PDO) and partly because it helps craft correct statements for the different DBMS it covers.
tennapel: As I’ve pointed out, we’re already using a homegrown abstraction layer, but it’s not complete. So to argue against using one now is all well and good, but that means you’re arguing for removing it from Txp, not just against adding it. :) And again, it’s not just abstraction, it is also an ORM.
Offline
Re: An idea for Txp 5, regarding db abstraction and more
Using an ORM is a great idea for Textpattern.
After having a look at Doctrine and Propel, I personally think they are overkill. It might be worth taking a look at other PHP ORM libraries – there are lots out there which look promising. Most seem to rely on PDO which I’ve not looked at before, but might there be occasions where PHP has been complied with out it? Or is it standard for PHP 5?
Offline
#12 2009-11-27 02:05:47
- Mary
- Sock Enthusiast
- Registered: 2004-06-27
- Posts: 6,236
Re: An idea for Txp 5, regarding db abstraction and more
Yes, PDO is standard for PHP5. :)
Offline