Обсуждение: PostgreSQL and PHP - some Great Bridge news
All, I'm pleased to announce two initiatives at Great Bridge aimed at improving the integration of PostgreSQL and PHP, and some exciting stuff that we're doing as a company to get behind PHP more fully. First, Great Bridge is partnering with Zend Technologies to include a fully-integrated installation of PHP in an upcoming Web developer's edition of Great Bridge PostgreSQL. In addition to professionally-supported PHP (and other open source Web technologies), we'll also give our customers the chance to purchase Zend's value-added PHP tools (IDE, cache, encoder, and more...) Zend is a major contributor to the open source PHP effort, and we're very happy to be working with them. Secondly, we're pleased to announce that three PHP core developers have joined the Great Bridge advisory committee- Rasmus Lerdorf, the creator of PHP; Thies Arntzen, an expert in PHP-database connectivity; and Sascha Schumann, PHP author and provider of high-performance webchat solutions. Rasmus, Thies, and Sascha will work with us to help craft our Web developer products and services, including (of course) a fully optimized free download package. We'll be putting some development energy into the PHP-Postgres interface, and look for other ways the two open source projects can help each other. We're also very interested in hacker feedback as to what you'd like to see in a software and service package that revolves around the Web development "stack." What kind of tools, building blocks, and applications would you like to see commercially supported? Don't be shy - please email me at ned@greatbridge.com with any suggestions. I'll also be at ApacheCon in a few weeks if you'd like to get together in person. Thanks, Ned -- ---------------------------------------------------- Ned Lilly e: ned@greatbridge.com Vice President w: www.greatbridge.com Evangelism / Hacker Relations v: 757.233.5523 Great Bridge, LLC f: 757.233.5555
Ned Lilly (ned@greatbridge.com) wrote: > We're also very interested in hacker feedback as to what you'd like to > see in a software and service package that revolves around the Web > development "stack." What kind of tools, building blocks, and > applications would you like to see commercially supported? Don't be shy > - please email me at ned@greatbridge.com with any suggestions. I'll > also be at ApacheCon in a few weeks if you'd like to get together in person. Hello Ned, It rooks like Great Bridge is really bringing the infrastructure people together. I'm glad to see that and apprecate your efforts. I've been hacking on the higher layers, developing a framework for online communities using PHP and Postgres. I am taking a similar approach as ArsDigita, releasing as much as I can. Obviously I'm not getting into bed with Oracle like they are. Philip put all his knowledge into a book which is available at http://www.arsdigita.com/asj/thebook/ , and I'm doing something somewhat similar at http://tinyplanet.ca/thebook/ . I'm not building something as big and oppressive as Zope, just something that is good enough to cover the majority of web publishing problems, and is effective and lightweight. In fact, I'm currently in touch with Stacie Parillo, Bruce Momjian's editor at Addison-Wesley, about getting "the book" published. I've got a book proposal mostly written and am working on chapters as you can see. I don't know if this is the direction that you're moving in, but if indeed it is, I'm interested in working with you. /Steve
> In fact, I'm currently in touch with Stacie Parillo, Bruce Momjian's > ... Whoops. I didn't notice that reply-to was set to the mailing list. Oh well. Apologies to those who were thinking "what?".
On Mon, 26 Mar 2001, Ned Lilly wrote: > All, > > I'm pleased to announce two initiatives at Great Bridge aimed at > improving the integration of PostgreSQL and PHP, and some exciting stuff > that we're doing as a company to get behind PHP more fully. > > First, Great Bridge is partnering with Zend Technologies to include a > fully-integrated installation of PHP in an upcoming Web developer's > edition of Great Bridge PostgreSQL. In addition to > professionally-supported PHP (and other open source Web technologies), > we'll also give our customers the chance to purchase Zend's value-added > PHP tools (IDE, cache, encoder, and more...) Zend is a major > contributor to the open source PHP effort, and we're very happy to be > working with them. > > Secondly, we're pleased to announce that three PHP core developers have > joined the Great Bridge advisory committee- Rasmus Lerdorf, the creator > of PHP; Thies Arntzen, an expert in PHP-database connectivity; and > Sascha Schumann, PHP author and provider of high-performance webchat > solutions. Rasmus, Thies, and Sascha will work with us to help craft > our Web developer products and services, including (of course) a fully > optimized free download package. We'll be putting some development > energy into the PHP-Postgres interface, and look for other ways the two > open source projects can help each other. > > We're also very interested in hacker feedback as to what you'd like to > see in a software and service package that revolves around the Web > development "stack." What kind of tools, building blocks, and > applications would you like to see commercially supported? Don't be shy > - please email me at ned@greatbridge.com with any suggestions. I'll > also be at ApacheCon in a few weeks if you'd like to get together in person. > Ned, I'd like to point you on Mason ( http://www.masonhq.com ) which is what many web developers use in real life. I'm using it from the very beginning with PostgreSQL and very happy. PHP and Mason have the same goal but different philosophy. Mason utilize modperl technology and pure perl and many people like this approach. So, if you said "one", why not to say "two" :-) Regards, Oleg > Thanks, > Ned > > Regards, Oleg _____________________________________________________________ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83
> We're also very interested in hacker feedback as to what you'd like to > see in a software and service package that revolves around the Web > development "stack." What kind of tools, building blocks, and > applications would you like to see commercially supported? Don't be shy > - please email me at ned@greatbridge.com with any suggestions. I'll > also be at ApacheCon in a few weeks if you'd like to get together in person. Well, I don't know if I'd really call myself a hacker, but I have done a bit of work with PG+PHP. I'm not exactly sure what I'm suggesting and how much it involves but here goes: It would be nice to have some sort of "toolkit" to create something similar to bound forms in MS Access (if you're familiar with it). I am currently working on a project in Access which at some point I think it would be nice to have a web interface too. I did a short example web "form" just for fun, but it was a lot of work. This sort of "toolkit" should make the job a bit easier. ... just thoughts ;) -Cedar
As an unabashed hacker, I'd like to point out one addition that I personally would really appreciate and find useful. Perl (and hence mod-perl and/or mason based stuff) has DBI and zope offers their SQL objects. Sadly, PHP's database stuff, while functional, is a fugly mess. A layer of abstraction gives at least the illusion of database independance. And while I certainly can (and have) written n'th tier layers that encapsulate all the pg_* php function calls, I personally don't _like_ having to do that kind of stuff. And given the choice, I always go with a tool that will do it for me. Of course yet-another-database-interface-layer while certainly a good and usefull piece of engineering wouldn't be particularly new and innovative. What _would_ be new and innovate, and maybe even impressive is a database interface layer that provides not just the usual database independant connect / query / result stuff but an organized, database independant way of accessing metadata. Writing SQL queries that derive metadata by futzing around with the pg_* tables works but is totally non-portable. What I would really like to see is a database interface layer that encapsulates all that nasty mess. Metadata and other introspective stuff is a glaring ommission from SQL. Well, you _did_ ask... :)
Hi, On Thu, 29 Mar 2001, Andrew Hammond wrote: > non-portable. What I would really like to see is a database interface > layer that encapsulates all that nasty mess. Metadata and other > introspective stuff is a glaring ommission from SQL. Could you develop this part a little bit more. I'm interested about it. Best regards, Jesus.
>
>Of course yet-another-database-interface-layer while certainly a good
>and usefull piece of engineering wouldn't be particularly new and
>innovative. What _would_ be new and innovate, and maybe even impressive
>is a database interface layer that provides not just the usual database
>independant connect / query / result stuff but an organized, database
>independant way of accessing metadata. Writing SQL queries that derive
>metadata by futzing around with the pg_* tables works but is totally
>non-portable. What I would really like to see is a database interface
>layer that encapsulates all that nasty mess. Metadata and other
>introspective stuff is a glaring ommission from SQL.
You should see this pear tutorial. Pear have an abstraction layer library
for databases.
http://www.phpbuilder.com/columns/allan20010115.php3
On Thu, Mar 29, 2001 at 05:16:54PM -0500, Andrew Hammond wrote:
> independant way of accessing metadata. Writing SQL queries that derive
> metadata by futzing around with the pg_* tables works but is totally
> non-portable. What I would really like to see is a database interface
> layer that encapsulates all that nasty mess. Metadata and other
> introspective stuff is a glaring ommission from SQL.
I have written something that does this in two directions: listing out the
indices, tables, columns, etc. For a simpleminded db abstraction layer for
work. I can provide code shortly.
IMHO the database "abstraction toolkits" are all missing the point. In my
scripts, I want my variables. Now. It failed? Not the concern of the
script.
So far I've laid out 5 functions:
# returns the value of that column or NULL if it's NULL
$scalar = db_value("SELECT column FROM table WHERE unique_id=5"):
# returns an array of values of these columns
$list = db_list("SELECT column FROM table");
# returns a hash[column] = value
$row = db_row("SELECT * FROM table WHERE unique_id=5");
# returns a array of hashes
$rows = db_row("SELECT * FROM table");
# for sending updates, etc.
$result = db_send("UPDATE/INSERT/DELETE whatever");
All the guts of connections, interation, freeing results, etc. are hidden.
I've even implemented failover behind the scenes.
Error handling is ambiguous with respect to NULL values, so that gets a -1
until something exception-like appears in the language. (And I'm not in a
hurry for that.)
This has turned out to be really effective.
One thing which would also be amazing (also borrowed from some simple-DBI
thing) is to automatically map primary keys into hashes. So when fetching a
bunch of rows that have a primary key:
$rows = db_row("SELECT pkey, value FORM table", 'user_id');
# $rows['somepkey'] is then a reference to the value of that key
Get it?
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
First off, I have to say that I'd never heard of PEAR before, but it looks like a good database abstraction layer. On Thu, Mar 29, 2001 at 10:17:44PM -0500, Stephen van Egmond wrote: > On Thu, Mar 29, 2001 at 05:16:54PM -0500, Andrew Hammond wrote: > > independant way of accessing metadata. Writing SQL queries that derive > > metadata by futzing around with the pg_* tables works but is totally > > non-portable. What I would really like to see is a database interface > > layer that encapsulates all that nasty mess. Metadata and other > > introspective stuff is a glaring ommission from SQL. > IMHO the database "abstraction toolkits" are all missing the point. You have definately missed my point. The key thing I'm interested in is META data and introspective abilities. For example, I'm NOT talking about selecting some data out of a table. I AM talking about getting a list of databases in the dbm, tables/objects in the database, columns in the table. That kind of thing. This is interesting because meta-data is exactly what you need if you want to write meta-programming. Like, say, a generic web / database interface... > In my scripts, I want my variables. Now. It failed? Not the concern > of the script. How do you intend to deal with runtime error situations? Debugging? Also, why didn't you use an object oriented approach so you could have multiple connections to multiple databases? Aside from those two rather serious issues, your api looks pretty good. Personally, I'd rename the get_rows function to something like get_table. get_rows is too close to get_row. I'd be apt to miss the s by accident and spend a few hours doing blank stare debugging. ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
On Thu, Mar 29, 2001 at 05:16:54PM -0500, Andrew Hammond wrote:
> independant way of accessing metadata. Writing SQL queries that derive
> metadata by futzing around with the pg_* tables works but is totally
> non-portable. What I would really like to see is a database interface
> layer that encapsulates all that nasty mess. Metadata and other
> introspective stuff is a glaring ommission from SQL.
I have written something that does this in two directions: listing out the
indices, tables, columns, etc. For a simpleminded db abstraction layer for
work. I can provide code shortly.
IMHO the database "abstraction toolkits" are all missing the point. In my
scripts, I want my variables. Now. It failed? Not the concern of the
script.
So far I've laid out 5 functions:
# returns the value of that column or NULL if it's NULL
$scalar = db_value("SELECT column FROM table WHERE unique_id=5"):
# returns an array of values of these columns
$list = db_list("SELECT column FROM table");
# returns a hash[column] = value
$row = db_row("SELECT * FROM table WHERE unique_id=5");
# returns a array of hashes
$rows = db_row("SELECT * FROM table");
# for sending updates, etc.
$result = db_send("UPDATE/INSERT/DELETE whatever");
All the guts of connections, interation, freeing results, etc. are hidden.
I've even implemented failover behind the scenes.
Error handling is ambiguous with respect to NULL values, so that gets a -1
until something exception-like appears in the language. (And I'm not in a
hurry for that.)
This has turned out to be really effective.
One thing which would also be amazing (also borrowed from some simple-DBI
thing) is to automatically map primary keys into hashes. So when fetching a
bunch of rows that have a primary key:
$rows = db_row("SELECT pkey, value FORM table", 'user_id');
# $rows['somepkey'] is then a reference to the value of that key
Get it?
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
First off, I have to say that I'd never heard of PEAR before, but it looks like a good database abstraction layer. On Thu, Mar 29, 2001 at 10:17:44PM -0500, Stephen van Egmond wrote: > On Thu, Mar 29, 2001 at 05:16:54PM -0500, Andrew Hammond wrote: > > independant way of accessing metadata. Writing SQL queries that derive > > metadata by futzing around with the pg_* tables works but is totally > > non-portable. What I would really like to see is a database interface > > layer that encapsulates all that nasty mess. Metadata and other > > introspective stuff is a glaring ommission from SQL. > IMHO the database "abstraction toolkits" are all missing the point. You have definately missed my point. The key thing I'm interested in is META data and introspective abilities. For example, I'm NOT talking about selecting some data out of a table. I AM talking about getting a list of databases in the dbm, tables/objects in the database, columns in the table. That kind of thing. This is interesting because meta-data is exactly what you need if you want to write meta-programming. Like, say, a generic web / database interface... > In my scripts, I want my variables. Now. It failed? Not the concern > of the script. How do you intend to deal with runtime error situations? Debugging? Also, why didn't you use an object oriented approach so you could have multiple connections to multiple databases? Aside from those two rather serious issues, your api looks pretty good. Personally, I'd rename the get_rows function to something like get_table. get_rows is too close to get_row. I'd be apt to miss the s by accident and spend a few hours doing blank stare debugging. ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster