Hi: I'm new to Drupal, but have long involvement in the PHP community. For instance, I'm the lead maintainer of PEAR's DB package and am involved with the PEAR documentation and website teams. A client of mine needs a CMS and I'm very impressed with how well the Drupal website is organized. I'm also enjoying Drupal's code itself. I submitted two code maintenance patches: http://drupal.org/node/19609 http://drupal.org/node/19474 One more thing I would like to do is make multi-site installations easier by providing scripts for performing the table name prefix substitutions. As I move forward with helping this client, I'm sure I'll come across more ways to improve Drupal. To these ends, I'm interested in obtaining the ability to make commits to the repository, please. Hmm, now that I'm looking at http://drupal.org/node/19474 I see people have commented on it. That's great. I'm used to bug systems sending an email when someone comments. I didn't receive such emails in response to these people's comments. Does Drupal's system not do that or am I missing something? My email address is correct, since I got the initial confirmation when setting up my account. Sincerely, --Dan -- T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y data intensive web and database programming http://www.AnalysisAndSolutions.com/ 4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409
Hi Dan, Nice to see you here too :)
As I move forward with helping this client, I'm sure I'll come across more ways to improve Drupal. To these ends, I'm interested in obtaining the ability to make commits to the repository, please.
Hmm, now that I'm looking at http://drupal.org/node/19474 I see people have commented on it. That's great. I'm used to bug systems sending an email when someone comments. I didn't receive such emails in response to these people's comments. Does Drupal's system not do that or am I missing something? My email address is correct, since I got the initial confirmation when setting up my account.
On Mar 28, 2005, at 5:02 PM, Daniel Convissor wrote:
Hi: Welcome!
First off, you should probably take a look at the Contributor's Guide: http://drupal.org/node/316
As I move forward with helping this client, I'm sure I'll come across more ways to improve Drupal. To these ends, I'm interested in obtaining the ability to make commits to the repository, please.
You can apply for a CVS account here: http://drupal.org/cvs-account Note that this only applies to the contributions repository. Commit access to the core repository is limited to three trusted individuals at the moment; contributions that apply to core (as opposed to add-on modules and themes) should be submitted in the form of patches, as you've already done.
Hmm, now that I'm looking at http://drupal.org/node/19474 I see people have commented on it. That's great. I'm used to bug systems sending an email when someone comments. I didn't receive such emails in response to these people's comments. Does Drupal's system not do that or am I missing something? My email address is correct, since I got the initial confirmation when setting up my account.
You can subscribe to e-mail notifications of issues for any Drupal project, but I don't believe the system automatically notifies people who have submitted a particular bug report. This would be a feature request for project.module. Good to have you aboard! -- Jonathan Chaffer Applications Developer, structure:interactive (616) 364-7423 http://www.structureinteractive.com/
Hey: On Mon, Mar 28, 2005 at 05:10:21PM -0500, Jonathan Chaffer wrote:
First off, you should probably take a look at the Contributor's Guide:
Did before submitting the first patch.
access to the core repository is limited to three trusted individuals at the moment
Ah. Okay.
You can subscribe to e-mail notifications of issues for any Drupal project
Once I subscribed to the devel list, I noticed that items get posted there. That'll suffice for my purposes. Thanks, --Dan -- T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y data intensive web and database programming http://www.AnalysisAndSolutions.com/ 4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409
On 29 Mar 2005, at 12:02 AM, Daniel Convissor wrote:
I'm new to Drupal, but have long involvement in the PHP community. For instance, I'm the lead maintainer of PEAR's DB package and am involved with the PEAR documentation and website teams. I hope you won't be too displeased with the fact that we've deprecated our PEAR db support (which was only being used for postgres). I just found it was easier and simpler maintaining the postgres port when not requiring external libraries that needed to be installed and managed.
Drupal aims to have as few dependencies as possible, and it will take a lot of convincing the get Drupal dependent on any PEAR packages =).
One more thing I would like to do is make multi-site installations easier by providing scripts for performing the table name prefix substitutions. The new install system being prepared for 4.7 will handle this automagically for the user, but patches for the time being would be very welcome.
As I move forward with helping this client, I'm sure I'll come across more ways to improve Drupal. To these ends, I'm interested in obtaining the ability to make commits to the repository, please.
Cool. Good to have you on board. -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
Hi Adrian: On Tue, Mar 29, 2005 at 03:53:03PM +0200, Adrian Rossouw wrote:
I hope you won't be too displeased with the fact that we've deprecated our PEAR db support ... Drupal aims to have as few dependencies as possible, and it will take a lot of convincing the get Drupal dependent on any PEAR packages =).
I understand your concerns. I think the benefits of supporting a broad range of DBMS's outweighs such concerns because abstraction allows the end users more flexibility. Do note, I'm not lobbying for you to change anything, just commenting.
One more thing I would like to do is make multi-site installations easier by providing scripts for performing the table name prefix substitutions.
The new install system being prepared for 4.7 will handle this automagically for the user, but patches for the time being would be very welcome.
Nice. Is this new install system stuff in CVS yet or is it only theoretical at this point? If in CVS, where? If not, do you have any code yet? If so, give me a peak. I'm asking because why should anyone (aka ME :) spend time whipping up something if someone else has already done the work? :) Thanks, --Dan -- T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y data intensive web and database programming http://www.AnalysisAndSolutions.com/ 4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409
On Tue, 29 Mar 2005 11:22:04 -0500, Daniel Convissor <danielc@analysisandsolutions.com> wrote:
The new install system being prepared for 4.7 will handle this automagically for the user, but patches for the time being would be very welcome.
Nice. Is this new install system stuff in CVS yet or is it only theoretical at this point? If in CVS, where? If not, do you have any code yet? If so, give me a peak. I'm asking because why should anyone (aka ME :) spend time whipping up something if someone else has already done the work? :)
There is work being done for CivicSpace and Bryght to create a very nice Drupal installer. If you download and install CivicSpace, you can give ours a try -- but there does need to be some work done to unify the work that Adrian is doing with the work that we're doing. In any case, it would be great for you take a look at these two systems and explore overlaps and opportunities for generalizing their design/implementations. Chris
Hi: On Tue, Mar 29, 2005 at 12:07:35PM -0800, Chris Messina wrote:
There is work being done for CivicSpace and Bryght to create a very nice Drupal installer. If you download and install CivicSpace, you can give ours a try
Ah. I did a checkout of civicspace. I see in /install.php there's a install_create_tables() function that does the table name prefixing and execution. The approach taken there is similar to one I was considering (grabbing the query file and splitting it). Unfortunately, at this time, this script doesn't handle the array syntax for $db_prefix, though, of course, that can be changed. Another tack in my mind is making a PHP script which would take the one static query file, doing preg_replace and then saving the results to a new query file. The user would then run the new query file. Yet another is to have each table be a separate query file which the install script sucks up, adjusts and executes as needed. All of the methods I was thinking of would go through the subdirectories in /sites, do include settings.php to get the various $db_prefix'es the user desires. Hey, Adrian, how about letting us see what you've come up with for this issue? Thanks, --Dan -- T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y data intensive web and database programming http://www.AnalysisAndSolutions.com/ 4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409
On Tue, Mar 29, 2005 at 03:54:42PM -0500, Daniel Convissor wrote:
Yet another is to have each table be a separate query file which the install script sucks up, adjusts and executes as needed.
Oh, here's a link to a similar system I put together: http://www.analysisandsolutions.com/presentations/portability/slides/create-... --Dan -- T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y data intensive web and database programming http://www.AnalysisAndSolutions.com/ 4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409
Daniel - do you know much about the MDB2 XML Schema?. Would it be easy to use that in our project? One of the more painful items around here is maintaining schemas for postgres and mysql. if we add more, the burden will be bad. this is one reason why mssql support faded away. for those who don't know, MDB2 is a PEAR project which defined a database independant way to define tables, indexes, etc. see http://www.backendmedia.de/MDB2/docs/xml_schema_documentation.html -moshe Daniel Convissor wrote:
On Tue, Mar 29, 2005 at 03:54:42PM -0500, Daniel Convissor wrote:
Yet another is to have each table be a separate query file which the install script sucks up, adjusts and executes as needed.
Oh, here's a link to a similar system I put together: http://www.analysisandsolutions.com/presentations/portability/slides/create-...
--Dan
Hey Moshe: On Tue, Mar 29, 2005 at 05:10:04PM -0500, Moshe Weitzman wrote:
Daniel - do you know much about the MDB2 XML Schema?. Would it be easy to use that in our project?
Yes. I'm somewhat involved with MDB2 development. I was going to suggest it, but people mentioned not wanting to rely on external packages. --Dan -- T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y data intensive web and database programming http://www.AnalysisAndSolutions.com/ 4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409
Daniel - do you know much about the MDB2 XML Schema?. Would it be easy to use that in our project?
Yes. I'm somewhat involved with MDB2 development. I was going to suggest it, but people mentioned not wanting to rely on external packages.
I think what we want to minimize are dependencies. We don't mind bundling other people's code when it makes sense. See xmlrpc.inc and phptemplate engine for examples. Is MDB2 engineered to let other projects use its schema parser/writer? If so, we would consider using it. If the schema stuff requires the rest of PEAR, then we would be unlikely to use it. Aslo, how close are you to offerring support for more RDBMS? Right now the only 2 that are supported are the ones we already have. -moshe
offerring support for more RDBMS? Right now the only 2 that are supported are the ones we already have.
Aye, but with the forthcoming PHP 5.1 with its included PDO I plan to do a PDO layer which would expand the possibilities a lot. PDO supports many DBs, and it's thin, I think it'll be good for us. I am worried about the schema. It'd be _very_ difficult to maintain the schemas for all RDBMs which PDO support. Regards NK
Hi: On Wed, Mar 30, 2005 at 04:24:23PM +0200, Karoly Negyesi wrote:
Aye, but with the forthcoming PHP 5.1 with its included PDO I plan to do a PDO layer which would expand the possibilities a lot. PDO supports many DBs, and it's thin, I think it'll be good for us.
It is, but it will be a long time until PHP 5.1 is widely available on web hosts.
It'd be _very_ difficult to maintain the schemas for all RDBMs which PDO support.
As mentioned yesterday, I came up with a simpler schema browser/builder which y'all might want to adopt. While it uses PEAR DB, that can be fairly easily swapped out for Drupal's database functions. http://www.analysisandsolutions.com/presentations/portability/slides/create-... Since I last posted that URI, I tweaked the file to provide links to the source code for the building scripts and a link to the .tgz containing the source and presentation. Subsequent to putting that presentation together, I've adjusted that system. Rather than setting the properties using methods, the new portability class is a bit more elegant, declaring/setting the properties in separate DBMS specific classes that extend the base class. --Dan -- T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y data intensive web and database programming http://www.AnalysisAndSolutions.com/ 4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409
I see that PEAR MDB2 project released their unified schema manager as a separate project - http://pear.php.net/package/MDB2_Schema/. This could be useful for us. Once again, the benefit is that we would only have to manage 1 schema and then this package would handle translating to mysql, postgres, mssql, etc. This would help us in the schema setup files and in the updates.inc. further, if Contrib modules could get on board with this we would have much better postgres support there.
On Fri, 8 Apr 2005, Moshe Weitzman wrote:
I see that PEAR MDB2 project released their unified schema manager as a separate project - http://pear.php.net/package/MDB2_Schema/. This could be useful for us.
I agree. However in its present state it is a 0.1.0 (beta) with no end user docs. Cheers, Gerhard
Hi Moshe: On Wed, Mar 30, 2005 at 09:12:50AM -0500, Moshe Weitzman wrote:
If the schema stuff requires the rest of PEAR, then we would be unlikely to use it.
MDB2 uses PEAR.php for error handling.
Aslo, how close are you to offerring support for more RDBMS? Right now the only 2 that are supported are the ones we already have.
That's not accurate. MDB2 has good support for these extensions: mysql, mysqli, pgsql, oci8, ibase (incl. Firebird) and sqlite. The fbsql and mssql drivers are shaky. PEAR DB has solid, tested support for the following extensions: fbsql, ibase (incl. Firebird), informix, msql, mssql, mysql, mysqli, oci8, odbc, pgsql, sqlite and sybase. --Dan -- T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y data intensive web and database programming http://www.AnalysisAndSolutions.com/ 4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409
On Tue, Mar 29, 2005 at 03:54:42PM -0500, Daniel Convissor wrote:
All of the methods I was thinking of would go through the subdirectories in /sites, do include settings.php to get the various $db_prefix'es the user desires.
I have just whipped up a preliminary version of this function. Let me polish it up and post it on Wednesday. --Dan -- T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y data intensive web and database programming http://www.AnalysisAndSolutions.com/ 4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409
Hey:
On Tue, Mar 29, 2005 at 03:54:42PM -0500, Daniel Convissor wrote:
All of the methods I was thinking of would go through the subdirectories in /sites, do include settings.php to get the various $db_prefix'es the user desires.
Okay, please take a look at it: http://www.analysisandsolutions.com/drupal/create1.php Thanks, --Dan -- T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y data intensive web and database programming http://www.AnalysisAndSolutions.com/ 4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409
On 29 Mar 2005, at 10:54 PM, Daniel Convissor wrote:
Hey, Adrian, how about letting us see what you've come up with for this issue? In the next few days , possibly over the weekend.
Busy with the Bryght 1.0 release too .. but I did spend a bunch of time on it this weekend. -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
Hi Adrian: On Wed, Mar 30, 2005 at 06:46:54PM +0200, Adrian Rossouw wrote:
Busy with the Bryght 1.0 release too .. but I did spend a bunch of time on it this weekend.
As you probably saw, I posted code for gathering the site settings from /drupal/site/*/settings.php. Hmm... I'm looking at the status for the default settings.php and see it has no tags. When is this new sites settings system slated for implementation? It seems like 4.6. I see y'all didn't make a tag for the 4.6.0 RC that was released. Wondering why... It comes in handy to tag all releases. Is your build system for the new system or old system? If it's using the existing conf.php settings system, my gather_site_settings() function can be easily tweaked to parse those files into an array of the same structure. Thus, if the table creation functions use that array, it can work for either of the settings system. Do you already have code for doing the table name prefixing and table creation? If so, can you email me off list with what you have so I can provide feedback or even do some coding, please. If not, I can whip something up. Thanks, --Dan -- T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y data intensive web and database programming http://www.AnalysisAndSolutions.com/ 4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409
Daniel Convissor wrote:
I see y'all didn't make a tag for the 4.6.0 RC that was released. The release candidate is packaged from cvs HEAD.
It comes in handy to tag all releases. It will have a tag when it's released :) Right now it's a release candidate, not a release...
-- adrinux (aka Adrian Simmons) <http://adrinux.perlucida.com> e-mail <mailto:adrinux@gmail.com> AOL/Yahoo IM: perlucida, Microsoft: adrian@perlucida.com
Hi: On Wed, Mar 30, 2005 at 07:37:40PM +0100, Adrian Simmons wrote:
It will have a tag when it's released :) Right now it's a release candidate, not a release...
I'm accustomed to RC's being numbered and having a specific composition which everyone can reference. It seems Drupal's RC is just a regular CVS snapshot which changes over time. --Dan -- T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y data intensive web and database programming http://www.AnalysisAndSolutions.com/ 4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409
I'm accustomed to RC's being numbered and having a specific composition which everyone can reference. It seems Drupal's RC is just a regular CVS snapshot which changes over time.
... which is considered now stable enough that non-developers are encouraged to test it. One might expect that the DB structure does not change (significantly...)
On Mar 30, 2005, at 1:58 PM, Daniel Convissor wrote:
On Wed, Mar 30, 2005 at 07:37:40PM +0100, Adrian Simmons wrote:
It will have a tag when it's released :) Right now it's a release candidate, not a release...
I'm accustomed to RC's being numbered and having a specific composition which everyone can reference. It seems Drupal's RC is just a regular CVS snapshot which changes over time.
This is so, and I believe I'm on record as wanting it to change. The ability for bug reporters to refer to specific builds is a very good thing. I think this is a feature we need desperately, right along with the ability for contrib projects to have multiple releases during a single Drupal release cycle. -- Jonathan Chaffer Applications Developer, structure:interactive (616) 364-7423 http://www.structureinteractive.com/
participants (9)
-
Adrian Rossouw -
Adrian Simmons -
Chris Messina -
Daniel Convissor -
Gabor Hojtsy -
Gerhard Killesreiter -
Jonathan Chaffer -
Karoly Negyesi -
Moshe Weitzman