Hi,

This is a reply to an email exchange with Manuel that I think is of
general interest to the list

I was talking about some additions that have come out of the "metapear"
project (merger of PEAR DB and Metabase).

As a side note: until I get some level of feedback from the PEAR folks I
will not continue development of "metapear" because to me the main point
of "metapear" was to make Metabase fit the needs of the PEAR folks so
that it will be distributed as part of PEAR.

Anyways ...

> > option of getting associative arrays as the result set
>
> Yes, but isn't this counterproductive to the whole point of fetching
> result set rows in bulk? I am afraid that not only it will not provide
a
> faster solution but it also will bloat Metabase base classes further.
> How much extra code does it require?

Yes, I actually never needed it ... dunno is anyone even has requested
it from Metabase?

Anyways its probably better not to include it going by the issues that
interbase seems to make with PEAR Db with this exact feature

> > and using FetchResultArray instead of FetchResult in the new fetch
> > methods to increase performance
>
> Good, I am not yet sure what this means but sounds good.

Right now you use mysql_result in FetchResult
But I think that mysql_fetch_row is faster from what I have gathered

By employing FetchResultArray instead of FetchResult I am hoping to get
a little speed improvement

One thing that I did not mention is my last email is adding something
that PEAR DB has:
DB::getAssoc() --  Fetch the result set as an associative array using
the first column as the key.

I am not interested in the associative array part but more in a function
that would allow me to specify which column is supposed to be used as
the key to the twodimensional result set array

I actually need something like this right now.
This would allow fetching data in one bulk and then using it quite
flexibly later on. In my case I use it to build a select box multiple
times that does not include all items in all instances. So I can go and
grab all the relevant data once and then can just run a for loop across
all allowed id's and taking the data from that twodimensional array by
using the id as the key (hope this is somewhat undertstandable)

Do you think that such a function would make sense?

Best regards,
Lukas Smith
smith@...
_______________________________
  DybNet Internet Solutions GbR
  Alt Moabit 89
  10559 Berlin
  Germany
  Tel. : +49 30 83 22 50 00
  Fax : +49 30 83 22 50 07
  www.dybnet.de info@...
_______________________________

> -----Original Message-----
> From: mlemos@... [mailto:mlemos@...] On
Behalf
> Of Manuel Lemos
> Sent: Thursday, February 28, 2002 9:40 PM
> To: Lukas Smith
> Subject: Re: metapear
>
> Hello,
>
> Lukas Smith wrote:
> >
> > Hi,
> >
> > well nobody contacted me about metapear ..
>
> Unfortunately, I am not surprised. Since the beginning they always
seem
> to be stalling the process to discourage us to go ahead.
>
> Never mind, lets just not make that a big deal. Metabase development
> will continue and there is more and more people willing to contribut
to
> it as it is.
>
>
> > so I guess I will then turn some of the additions I made into
patches
> > for Metabase
> >
> > mainly 3 things:
> > bulk set for prepared queries
>
> Good!
>
>

>
>
>
>
> > those should be coming in the next couple of days
>
>
> Nice. I am sorry I haven't been very responsive lately, but that is
> because the migration works of the PHP Classes site.
>
> Anyway, there may be some good news for Metabase development soon.
>
> Regards,
> Manuel Lemos

I have managed to (finally) make a connection and establish some queries
with an Access db I am using with the following code part:

//defineDSN based db setup
$databaseSetup_array = array(
                         "Type"=>"odbc",
                         "User"=>"",
                         "Password"=>"",
                         "IncludePath"=>$include_metabasePath,
                         "Options"=>array(
                         "DBADSN"=>$dbname,
                         "DBAUser"=>"",
                         "DBAPassword"=>"",
                         "UseDefaultValues"=>0,
                         "UseDecimalScale"=>0,
                         "UseTransactions"=>0));


$error=MetabaseSetupDatabase($databaseSetup_array,$database);

(thanks to David for his example some weeks ago re stockDB)
----
I have used the following code in an ini file for connecting to an Access db
using ADO successfully as a DSNless connection, so I guess the bits must be
in here somewhere for Metabase:

[ODBC]
Provider=MSDASQL
Driver=Microsoft Access Driver (*.mdb)
DriverId=25
Fil=MS Access
ImplicitCommitSync=Yes
MaxBufferSize=2048
MaxScanRows=8
PageTimeout=5
SafeTransactions=0
Threads=3
DatabaseTerm=DBQ
--------------
and have been able to connect using the ADODB wrappers for a DNSless
connection as follows:
/*  x ADODB DSNLess connection
$db = &ADONewConnection("ado_access");

print "<h1>Connecting DSN-less $db->databaseType...</h1>";

$myDSN="PROVIDER=MSDASQL;"
         ."DRIVER={Microsoft Access Driver (*.mdb)};"
         ."DBQ=c:/aSBio/database/db_access/_dataset.mdb;"
         ."UID=;"
         ."PWD=;"  ;

$db->Connect($myDSN);
---------------------------
currently running pHp and Apache as CGI under WindowsME

I assume Metabase can actually connect to odbc as a DSNLess connection?

What I would like to do is also access odbc databases as a DSNless
connection, but cannot see in the info provided on Metabase how to
accomplish this.

Can someone please assist in laying out the required Metabase connection
parameters as trial and error so far is consuming too much time and cant
seem to suss out.

Regards
Peter M

Hello,

Peter M wrote:
> $myDSN="PROVIDER=MSDASQL;"
>         ."DRIVER={Microsoft Access Driver (*.mdb)};"
>         ."DBQ=c:/aSBio/database/db_access/_dataset.mdb;"
>         ."UID=;"
>         ."PWD=;"  ;
>
> $db->Connect($myDSN);
> ---------------------------
> currently running pHp and Apache as CGI under WindowsME
>
> I assume Metabase can actually connect to odbc as a DSNLess connection?
>
> What I would like to do is also access odbc databases as a DSNless
> connection, but cannot see in the info provided on Metabase how to
> accomplish this.

Just use the DSN string above to set the database name with the
MetabaseSetDatabase function.

Regards,
Manuel Lemos

Manuel

Thanks for reply, apols for no earlier response, as doing this dev part time
as a partimer on php at moment.

Have tried your suggestion, but still not clear on the MetabaseSetupDatabase
parameters to set. Have tried the database name as the dsn string, but dont
get past the setupdatabase function erroring out with various messages
depending on what I put in as the parameters (usually some ODBC error cant
connect or such)

what do I need for the MetabaseSetupDatabase for the whole thing to work?

I have tried various options to the following $databaseSetup_array including
what works for a DSN connection down to a simple array spec as below:

$databaseSetup_array = array("Type"=>"odbc");

$error=MetabaseSetupDatabase($databaseSetup_array,$database);
if($error!="")
{
echo "Error(MetabaseSetupDatabase): $error\n";
exit;
}

$dbname="PROVIDER=MSDASQL;"
         ."DRIVER=Microsoft Access Driver (*.mdb);"
         ."DBQ=e:/aSoilsBio/database/db_access/_dataset.mdb;"
         ."UID=;"
         ."PWD=;"  ;


/*$dbname="DRIVER=Microsoft Access Driver (*.mdb);"
         ."DBQ=e:/aSoilsBio/database/db_access/_dataset.mdb;"
         ."UID=;"
         ."PWD=;"  ;
*/
//$dbname="e:/aSoilsBio/database/db_access/_dataset.mdb";

$previousMetabaseSetDatabase=MetabaseSetDatabase($database,$dbname);

errors returned: "it was not specified an existing DBMS driver file "

or if expand the  $databaseSetup_array to
$databaseSetup_array = array(
                         "Type"=>"odbc",
                         "User"=>"",
                         "Password"=>"",
                         "IncludePath"=>$include_metabasePath);
get the following error:  "Could not connect to ODBC server: IM002
[Microsoft][ODBC Driver Manager] Data source name not found and no default
driver specified "

etc etc etc

Any help appreciated, its no doubt real simple and easy but seem to have a
complete block on getting past this point and cant suss out the required
parameters even by trial and error.

Peter M

------------------------------------------------------------------------

There are 2 messages in this issue.

Topics in this digest:

       1. connecting to a DSN less Accesss db
            From: "Peter M" <fourfronttech@...>
       2. Re: connecting to a DSN less Accesss db
            From: Manuel Lemos <mlemos@...>


________________________________________________________________________
________________________________________________________________________

Message: 1
    Date: Mon, 4 Mar 2002 12:59:57 +1300
    From: "Peter M" <fourfronttech@...>
Subject: connecting to a DSN less Accesss db

I have managed to (finally) make a connection and establish some queries
with an Access db I am using with the following code part:

//defineDSN based db setup
$databaseSetup_array = array(
                         "Type"=>"odbc",
                         "User"=>"",
                         "Password"=>"",
                         "IncludePath"=>$include_metabasePath,
                         "Options"=>array(
                         "DBADSN"=>$dbname,
                         "DBAUser"=>"",
                         "DBAPassword"=>"",
                         "UseDefaultValues"=>0,
                         "UseDecimalScale"=>0,
                         "UseTransactions"=>0));


$error=MetabaseSetupDatabase($databaseSetup_array,$database);

(thanks to David for his example some weeks ago re stockDB)
----
I have used the following code in an ini file for connecting to an Access db
using ADO successfully as a DSNless connection, so I guess the bits must be
in here somewhere for Metabase:

[ODBC]
Provider=MSDASQL
Driver=Microsoft Access Driver (*.mdb)
DriverId=25
Fil=MS Access
ImplicitCommitSync=Yes
MaxBufferSize=2048
MaxScanRows=8
PageTimeout=5
SafeTransactions=0
Threads=3
DatabaseTerm=DBQ
--------------
and have been able to connect using the ADODB wrappers for a DNSless
connection as follows:
/*  x ADODB DSNLess connection
$db = &ADONewConnection("ado_access");

print "<h1>Connecting DSN-less $db->databaseType...</h1>";

$myDSN="PROVIDER=MSDASQL;"
         ."DRIVER={Microsoft Access Driver (*.mdb)};"
         ."DBQ=c:/aSBio/database/db_access/_dataset.mdb;"
         ."UID=;"
         ."PWD=;"  ;

$db->Connect($myDSN);
---------------------------
currently running pHp and Apache as CGI under WindowsME

I assume Metabase can actually connect to odbc as a DSNLess connection?

What I would like to do is also access odbc databases as a DSNless
connection, but cannot see in the info provided on Metabase how to
accomplish this.

Can someone please assist in laying out the required Metabase connection
parameters as trial and error so far is consuming too much time and cant
seem to suss out.

Regards
Peter M



________________________________________________________________________
________________________________________________________________________

Message: 2
    Date: Sun, 03 Mar 2002 23:27:32 -0300
    From: Manuel Lemos <mlemos@...>
Subject: Re: connecting to a DSN less Accesss db

Hello,

Peter M wrote:
> $myDSN="PROVIDER=MSDASQL;"
>         ."DRIVER={Microsoft Access Driver (*.mdb)};"
>         ."DBQ=c:/aSBio/database/db_access/_dataset.mdb;"
>         ."UID=;"
>         ."PWD=;"  ;
>
> $db->Connect($myDSN);
> ---------------------------
> currently running pHp and Apache as CGI under WindowsME
>
> I assume Metabase can actually connect to odbc as a DSNLess connection?
>
> What I would like to do is also access odbc databases as a DSNless
> connection, but cannot see in the info provided on Metabase how to
> accomplish this.

Just use the DSN string above to set the database name with the
MetabaseSetDatabase function.

Regards,
Manuel Lemos


________________________________________________________________________
________________________________________________________________________



Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

Hello,

Peter M wrote:
>
> Manuel
>
> Thanks for reply, apols for no earlier response, as doing this dev part time
> as a partimer on php at moment.
>
> Have tried your suggestion, but still not clear on the MetabaseSetupDatabase
> parameters to set. Have tried the database name as the dsn string, but dont
> get past the setupdatabase function erroring out with various messages
> depending on what I put in as the parameters (usually some ODBC error cant
> connect or such)
>
> what do I need for the MetabaseSetupDatabase for the whole thing to work?

The database name is set with MetabaseSetDatabase and not with
MetabaseSetupDatabase.



> errors returned: "it was not specified an existing DBMS driver file "

Yes, that means the IncludePath may be missing.


> or if expand the  $databaseSetup_array to
> $databaseSetup_array = array(
>                         "Type"=>"odbc",
>                         "User"=>"",
>                         "Password"=>"",
>                         "IncludePath"=>$include_metabasePath);
> get the following error:  "Could not connect to ODBC server: IM002
> [Microsoft][ODBC Driver Manager] Data source name not found and no default
> driver specified "

You need to set the DBAUser, DBAPassword and DBADSN in
MetabaseSetupDatabase. This should not have been this way but since I
had BLOB support I start needing to connect to the database to query the
ODBC supported datatypes so I could figure if and how it supports BLOBs.
I need to think if there is another solution for this, but for now set
those database setup arguments that should work for you.

Regards,
Manuel Lemos

Manuel

Thanks for reply, apols for no earlier response, as doing this dev
part time as a partimer on php at moment.

Have tried your suggestion, but still not clear on the
MetabaseSetupDatabase parameters to set. Have tried the database name
as the dsn string, but dont get past the setupdatabase function
erroring out with various messages depending on what I put in as the
parameters (usually some ODBC error cant connect or such)

what do I need for the MetabaseSetupDatabase for the whole thing to
work?

I have tried various options to the following $databaseSetup_array
including what works for a DSN connection down to a simple array spec
as below:

$databaseSetup_array = array("Type"=>"odbc");

$error=MetabaseSetupDatabase($databaseSetup_array,$database);
if($error!="")
{
echo "Error(MetabaseSetupDatabase): $error\n";
exit;
}

$dbname="PROVIDER=MSDASQL;"
         ."DRIVER=Microsoft Access Driver (*.mdb);"
         ."DBQ=e:/aSoilsBio/database/db_access/_dataset.mdb;"
         ."UID=;"
         ."PWD=;"  ;


/*$dbname="DRIVER=Microsoft Access Driver (*.mdb);"
         ."DBQ=e:/aSoilsBio/database/db_access/_dataset.mdb;"
         ."UID=;"
         ."PWD=;"  ;
*/
//$dbname="e:/aSoilsBio/database/db_access/_dataset.mdb";

$previousMetabaseSetDatabase=MetabaseSetDatabase($database,$dbname);

errors returned: "it was not specified an existing DBMS driver file "

or if expand the  $databaseSetup_array to
$databaseSetup_array = array(
                         "Type"=>"odbc",
                         "User"=>"",
                         "Password"=>"",
                         "IncludePath"=>$include_metabasePath);
get the following error:  "Could not connect to ODBC server: IM002
[Microsoft][ODBC Driver Manager] Data source name not found and no
default driver specified "

etc etc etc

Any help appreciated, its no doubt real simple and easy but seem to
have a complete block on getting past this point and cant suss out
the required parameters even by trial and error.

Peter M

--- In metabase-dev@y..., Manuel Lemos <mlemos@a...> wrote:
> Hello,
>
> Peter M wrote:
> > $myDSN="PROVIDER=MSDASQL;"
> >         ."DRIVER={Microsoft Access Driver (*.mdb)};"
> >         ."DBQ=c:/aSBio/database/db_access/_dataset.mdb;"
> >         ."UID=;"
> >         ."PWD=;"  ;
> >
> > $db->Connect($myDSN);
> > ---------------------------
> > currently running pHp and Apache as CGI under WindowsME
> >
> > I assume Metabase can actually connect to odbc as a DSNLess
connection?
> >
> > What I would like to do is also access odbc databases as a DSNless
> > connection, but cannot see in the info provided on Metabase how to
> > accomplish this.
>
> Just use the DSN string above to set the database name with the
> MetabaseSetDatabase function.
>
> Regards,
> Manuel Lemos

Lukas,

If you are ready for testing we got no such announcement, and will now do
so.

As much as I and the other binarycloud developers can support you in this
effort, we can and will. Metapear is EXTREMELY important to us, so please
keep the lines of communication open so we can monitor your progress and
test your code.

I do not subscribe to the PEAR list because I get far too much mail as it
is, so please, _please_ cc: dev@....

I will place a copy of Metabase in CVS on monday, and put out a binarycloud
RFC that it be tested. I will then send you a detailed report of our
findings.

Please, don't give up on metapear - it is an important step forward.
Regardless of what PEAR people think (I don't know) the _binarycloud_ people
think what you're doing is important and worthwhile.

Please continue and we will offer what support we can.

best,

_alex

----- Original Message -----
From: "Lukas Smith" <smith@...>
To: "'Peter Bowyer'" <reywob@...>; <pear-dev@...>;
<metabase-dev@egroups.com>; "'binarycloud-dev'" <dev@...>
Sent: Sunday, March 17, 2002 4:52 AM
Subject: [binarycloud-dev] RE: [PEAR-DEV] What's happening with metapear?


> That is an interesting question :-)
>
> I have made several releases (www.dybnet.de/metapear ... and go grab
> metapear.zip) and I asked for feedback and got close to nothing.
>
> The thing is that metapear is that I don't see much point in spending
> any more time on metapear before I get some feedback from the PEAR
> folks. I actually wrote several lengthy emails on why I want feedback
> and what sort of feedback I would like to see.
>
> As such I actually already gave up on metapear and started turning some
> of the stuff I did for metapear into patches for Metabase. The other day
> Tomas was playing around with it a bit (he asked me about it on IRC) but
> he never told me if he liked any of it :-)
>
> Anyways if people are interested then I would really like to see replies
> to those feedback requests (if you want I can dig up those requests and
> repost them).
>
> Best regards,
> Lukas Smith
> smith@...
> _______________________________
>  DybNet Internet Solutions GbR
>  Alt Moabit 89
>  10559 Berlin
>  Germany
>  Tel. : +49 30 83 22 50 00
>  Fax : +49 30 83 22 50 07
>  www.dybnet.de info@...
> _______________________________
>
> > -----Original Message-----
> > From: Peter Bowyer [mailto:reywob@...]
> > Sent: Sunday, March 17, 2002 9:37 AM
> > To: pear-dev@...
> > Subject: [PEAR-DEV] What's happening with metapear?
> >
> > Hi,
> >
> > How's this coming on?  I'm really looking forward to using the XML
> schema
> > => database tables when it's released :-)
> >
> > Peter.
> >
> > --
> > Maple Design - quality web design and programming
> > http://www.mapledesign.co.uk
> >
> >
> > --
> > PEAR Development Mailing List (http://pear.php.net/)
> > To unsubscribe, visit: http://www.php.net/unsub.php
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

That is an interesting question :-)

I have made several releases (www.dybnet.de/metapear ... and go grab
metapear.zip) and I asked for feedback and got close to nothing.

The thing is that metapear is that I don't see much point in spending
any more time on metapear before I get some feedback from the PEAR
folks. I actually wrote several lengthy emails on why I want feedback
and what sort of feedback I would like to see.

As such I actually already gave up on metapear and started turning some
of the stuff I did for metapear into patches for Metabase. The other day
Tomas was playing around with it a bit (he asked me about it on IRC) but
he never told me if he liked any of it :-)

Anyways if people are interested then I would really like to see replies
to those feedback requests (if you want I can dig up those requests and
repost them).

Best regards,
Lukas Smith
smith@...
_______________________________
  DybNet Internet Solutions GbR
  Alt Moabit 89
  10559 Berlin
  Germany
  Tel. : +49 30 83 22 50 00
  Fax : +49 30 83 22 50 07
  www.dybnet.de info@...
_______________________________

> -----Original Message-----
> From: Peter Bowyer [mailto:reywob@...]
> Sent: Sunday, March 17, 2002 9:37 AM
> To: pear-dev@...
> Subject: [PEAR-DEV] What's happening with metapear?
>
> Hi,
>
> How's this coming on?  I'm really looking forward to using the XML
schema
> => database tables when it's released :-)
>
> Peter.
>
> --
> Maple Design - quality web design and programming
> http://www.mapledesign.co.uk
>
>
> --
> PEAR Development Mailing List (http://pear.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php

Great to hear that some people care :-)

Again I also think that this merger is both worthwhile and important.
Doing finishing this to be point of being production useable should be
possible to complete in about 2 weeks (even with the few time I have
available).

Seperating everything into components would then be the next step (dunno
how far Manuel is along with what he had planned in terms of seperating
the components within Metabase .. this could then be easily ported over
to metapear)

Best regards,
Lukas Smith
smith@...
_______________________________
  DybNet Internet Solutions GbR
  Alt Moabit 89
  10559 Berlin
  Germany
  Tel. : +49 30 83 22 50 00
  Fax : +49 30 83 22 50 07
  www.dybnet.de info@...
_______________________________

> -----Original Message-----
> From: alex black [mailto:enigma@...]
> Sent: Sunday, March 17, 2002 6:40 PM
> To: dev@...; 'Peter Bowyer';
pear-dev@...;
> metabase-dev@yahoogroups.com
> Subject: [metabase-dev] Re: [binarycloud-dev] RE: [PEAR-DEV] What's
> happening with metapear?
>
> Lukas,
>
> If you are ready for testing we got no such announcement, and will now
do
> so.
>
> As much as I and the other binarycloud developers can support you in
this
> effort, we can and will. Metapear is EXTREMELY important to us, so
please
> keep the lines of communication open so we can monitor your progress
and
> test your code.
>
> I do not subscribe to the PEAR list because I get far too much mail as
it
> is, so please, _please_ cc: dev@....
>
> I will place a copy of Metabase in CVS on monday, and put out a
> binarycloud
> RFC that it be tested. I will then send you a detailed report of our
> findings.
>
> Please, don't give up on metapear - it is an important step forward.
> Regardless of what PEAR people think (I don't know) the _binarycloud_
> people
> think what you're doing is important and worthwhile.
>
> Please continue and we will offer what support we can.
>
> best,
>
> _alex
>
> ----- Original Message -----
> From: "Lukas Smith" <smith@...>
> To: "'Peter Bowyer'" <reywob@...>; <pear-dev@...>;
> <metabase-dev@egroups.com>; "'binarycloud-dev'"
> <dev@...>
> Sent: Sunday, March 17, 2002 4:52 AM
> Subject: [binarycloud-dev] RE: [PEAR-DEV] What's happening with
metapear?
>
>
> > That is an interesting question :-)
> >
> > I have made several releases (www.dybnet.de/metapear ... and go grab
> > metapear.zip) and I asked for feedback and got close to nothing.
> >
> > The thing is that metapear is that I don't see much point in
spending
> > any more time on metapear before I get some feedback from the PEAR
> > folks. I actually wrote several lengthy emails on why I want
feedback
> > and what sort of feedback I would like to see.
> >
> > As such I actually already gave up on metapear and started turning
some
> > of the stuff I did for metapear into patches for Metabase. The other
day
> > Tomas was playing around with it a bit (he asked me about it on IRC)
but
> > he never told me if he liked any of it :-)
> >
> > Anyways if people are interested then I would really like to see
replies
> > to those feedback requests (if you want I can dig up those requests
and
> > repost them).
> >
> > Best regards,
> > Lukas Smith
> > smith@...
> > _______________________________
> >  DybNet Internet Solutions GbR
> >  Alt Moabit 89
> >  10559 Berlin
> >  Germany
> >  Tel. : +49 30 83 22 50 00
> >  Fax : +49 30 83 22 50 07
> >  www.dybnet.de info@...
> > _______________________________
> >
> > > -----Original Message-----
> > > From: Peter Bowyer [mailto:reywob@...]
> > > Sent: Sunday, March 17, 2002 9:37 AM
> > > To: pear-dev@...
> > > Subject: [PEAR-DEV] What's happening with metapear?
> > >
> > > Hi,
> > >
> > > How's this coming on?  I'm really looking forward to using the XML
> > schema
> > > => database tables when it's released :-)
> > >
> > > Peter.
> > >
> > > --
> > > Maple Design - quality web design and programming
> > > http://www.mapledesign.co.uk
> > >
> > >
> > > --
> > > PEAR Development Mailing List (http://pear.php.net/)
> > > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
> >
> >
---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@...
> > For additional commands, e-mail: dev-help@...
> >
> >
>
>
> ------------------------ Yahoo! Groups Sponsor
>
> To Unsubscribe, send a blank message to: metabase-dev-
> unsubscribe@eGroups.com
> Need other Metabase drivers? http://www.egroups.com/surveys/metabase-
> dev?id=263873
> Latest beta version: http://www.egroups.com/files/metabase-dev
> Vote on Metabase: http://www.zend.com/apps.php?id=122&single=1
>
>
> Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/
>

> Since I seem to have forgotten to send my release announcements to this
> mailinglist ...
>
> So all code can be found at www.dybnet.de/metapear

Cool, in CVS on Monday.

All (be people): I'm going to put up a testing RFC for this stuff... anyone
interested in taking it?

> This is just a proof of concept and is basically metabase with a bunch of
> pear related additions in terms of methods and a bit of pear error handling

Cool.

> There can still be a lot of code safed I think (especially with the get*()
> family of methods that are basically only slightly modified from the
> original pear code)

There is as always much to do :)

continues...
>> Aloha,
>>
>> I know this will turn into yet another difficult thread (if people even start
>> answering :-) ). All I can say right now is that I have been emailed in
>> private by both sides (someone from PEAR DB and Metabase) which is all fine
>> if
>> people want to keep it that way but which will obviously limit some of the
>> collaborative advantage that opensource development normally provides.

I have no such qualms about standing in public :)

Your efforts are timely and necessary. You will receive support from the
binarycloud camp, as we stand to benefit greatly from your efforts.
Eventually you may even find that some people that were doing core dev on
binarycloud are interested in helping with metapear.

>> Anyways as I have stated previously what I (and I assume everybody else
>> involved as well) want to have is the best features, API and performance
>> optimizations of both PEAR DB and Metabase in what I am now calling
>> "metapear".

As do I. I think this is the best of both worlds. Also dynamic loading of
components is important, as Metabase currently loads everything, which is
unnecessary. It still rocks, but there is obviously a lot to do. The most
important work that manual did with that code is real, _true_ field/datatype
level abstraction across multiple DMBSs - in that sense it is a true
abstraction layer.

Everything else about metabase, i.e. the API, loading, etc I think can be
either toasted and done over or tweaked until it's faster. I don't think
metabase will ever be as fast as ADODB (hock, spit), or PEAR:DB, because it
does so much more. At the same time I think there is quite a lot of stuff
that could be done to make it a lot faster.

>> slow but that is because no effort was made to make it fast. This should

Well said.

>> caching engine can do away with a lot of that overhead. Finally the current
>> Metabase (and therefore "metapear") always loads a lot of seldom used
>> functionality which will be moved to separate packages.

This is important and I'm glad you know about it / want to fix it.

>> In the end I want to have 2 wrappers and one core component. Metabase always
>> has had a wrapper in the form of mysql_interface.php. PEAR DB will also need
>> to get a wrapper most likely in order to keep BC with the old PEAR DB but not
>> bloat "metapear".

What do you mean by 2 wrappers? do you mean DBMS wrappers?

Oh nevermind I kept reading, I get it. A BC metabase wrapper and a BC PEARDB
wrapper?

>> Another question: Does "metapear" even need to be able to retrieve resultsets
>> step by step? I really do not see the advantage there. People should ensure

I have never used that nor do I particularly like the idea :)

>> need while they are allready working through the result set. So I would want
>> to throw those out as well.

Yep.

>> The basic idea here is to really reduce "metapear" to the absolute minimum of
>> methods. I think this is an important part of speeding "metapear" up and also

I agree - as long as you don't chuck anything that metabase was able to do
before.

Actually, on that subject I think the XML-schema-parsing/loading stuff could
be a separate package. That is the other _fantastically_ cool thing about
metabase (the XML schema stuff) which should stay. I think a separate
package makes sense though.

>> making the API nice and compact. I might be going too far though in my
>> suggestions. So again I am looking for comments.

Not so far. Everything you're saying synchs right up nicely with what I and
others have wanted for some time.

>> The other important issue is error handling/abstraction: In all of the
>> discussion I think one of the main issues was that Metabase requires 100%
>> portability while PEAR DB is mainly about a cross DB API and to a lesser
>> degree about portability. But portability is exactly what PEAR DB stands to
>> gain along with a lot of other stuff. So I would like to hear concepts about
>> how "metapear" should do this while keeping BC in mind.

This is an area where I really am tempted to say screw BC. :) Requiring
PEAR.php isn't that big of a deal, and I would _love_ to get proper PEAR
error objects from the abstraction layer, as that is the error standard
(PEAR's) that we use in binarycloud, with some extra metadata that we like
shoved in user_info :)

I think you might even want to abstract the error call interface a bit so
you can "detect" pear and use that error stuff or just use PHP's throw_error
or whatever that function is called.

>> gathered Metabase will be a bit easier for BC in that respect since Metabase
>> focuses on getting the developer information to manually debug while PEAR DB
>> tries to abstract error codes in order to allow code to act based on those. I

That is a key ++good thing about PEAR_DB. I want error messages with codes
so we can act on those codes in our own code and propagate meaningful
actions and messages up the render pipeline.

Very important to include codes, exactly the way PEAR does it now, which
works very well.

>> currently have not ha time enough to really think of a good solution that
>> will
>> please all parties and I would really like to hear a proposal as to how best
>> do this.

I'm interested in manuel's opinion on this. I think the way above would be
fine.

>> All of this are important steps in streamlining "metapear" so it is really
>> important to get some level of agreement on all of this. This will require
>> that people look at the actual code that is now in place within "metapear"
>> because I don't think that it makes sense for me to make these decisions
>> alone. I hope people will find the time and that people now have enough faith
>> in this merger that they feel that investing time will not turn out to be a
>> waste of time.

Lukas, so far your decisions have been 100% sound. So while I agree with you
about code review, at the same time I now completely trust your judgement.
So we'll give you feedback but don't let us hinder your progress.

Do what you think is right, check in once and a while, and if you happen to
miss something we'll fix it - a lot of people will use this :)

_a

At 08:04 PM 3/17/02 +0100, Lukas Smith wrote:
>Obviously seperating everything into packages is very easy. But I would
>like the including to happen automagically somehow :-)

Have a look at Smarty 2.0 <http://phpinsider.com>.  They do this and it
works brilliantly (but then what else do you expect when it's coded by
Monte and Andrei?) - they call it a plugin architecture, but I guess you
could call it a package architecture instead :-)

  >> Another question: Does "metapear" even need to be able to retrieve
resultsets
  >> step by step? I really do not see the advantage there. People should ensure

Not entirely sure what you mean, but if you're talking about the ability to do:
          while ($row = $result->fetchRow(DB_FETCHMODE_ASSOC)) {
                  // Massage the data
                  $data[] = $row;
          }

then I say we need this.

Also, the get*() methods in PEAR-DB are really useful - I know they add
overhead, but for ease of programming they are brilliant.

Regards,
Peter.

--
Maple Design - quality web design and programming
http://www.mapledesign.co.uk

> -----Original Message-----
> From: Alex Black [mailto:enigma@...]

> Everything else about metabase, i.e. the API, loading, etc I think can
be
> either toasted and done over or tweaked until it's faster. I don't
think
> metabase will ever be as fast as ADODB (hock, spit), or PEAR:DB,
because
> it
> does so much more. At the same time I think there is quite a lot of
stuff
> that could be done to make it a lot faster.

Actually I think if we find a nice solution to separate metapear into
packages then I think metapear can very well compete with PEAR DB in
performance (I think PEAR DB probably has some overhead with their
result object which if I got tomas right is not something that really
did much for them). I don't know enough about ADODB.

Obviously seperating everything into packages is very easy. But I would
like the including to happen automagically somehow :-)

> What do you mean by 2 wrappers? do you mean DBMS wrappers?
>
> Oh nevermind I kept reading, I get it. A BC metabase wrapper and a BC
> PEARDB
> wrapper?

Yeah exactly. Allthough metabase does not really not a wrapper .. just a
slightly modfied metabase_interface.php

> Lukas, so far your decisions have been 100% sound. So while I agree
with
> you
> about code review, at the same time I now completely trust your
judgement.
> So we'll give you feedback but don't let us hinder your progress.
>
> Do what you think is right, check in once and a while, and if you
happen
> to
> miss something we'll fix it - a lot of people will use this :)

thx :-)
one thing to keep in mind though: my strengths are mostly in design and
not so much in php coding as I am not all that experienced in php
coding. So even though my ideas might be sound, my code could maybe use
an experienced hand (if only to use php to the max).

Anyways I also think that the pear error handling (with their error code
abstraction) is the way to go (allthough Manuel does not quite agree
there). But I guess that had to happen anyways if "metapear" was to be
included into PEAR (which to me is the main reason for all of this).

Best regards,
Lukas Smith
smith@...
_______________________________
  DybNet Internet Solutions GbR
  Alt Moabit 89
  10559 Berlin
  Germany
  Tel. : +49 30 83 22 50 00
  Fax : +49 30 83 22 50 07
  www.dybnet.de info@...
_______________________________

>> could be done to make it a lot faster.
>>
> Actually I think if we find a nice solution to separate metapear into
> packages then I think metapear can very well compete with PEAR DB in
> performance (I think PEAR DB probably has some overhead with their result
> object which if I got tomas right is not something that really did much for

I agree. Though I think there will always be a (small) speed hit for the
proper datatype abstraction/translation. Which is of course fine with me
because it makes my applications portable in the real world

> Obviously seperating everything into packages is very easy. But I would like
> the including to happen automagically somehow :-)

Yepp! :)

>> Oh nevermind I kept reading, I get it. A BC metabase wrapper and a BC PEARDB
>> wrapper?
>>
> Yeah exactly. Allthough metabase does not really not a wrapper .. just a
> slightly modfied metabase_interface.php

Got it.

>> Do what you think is right, check in once and a while, and if you happen to
>> miss something we'll fix it - a lot of people will use this :)
>>
> thx :-) one thing to keep in mind though: my strengths are mostly in design
> and not so much in php coding as I am not all that experienced in php
> coding. So even though my ideas might be sound, my code could maybe use an
> experienced hand (if only to use php to the max).

Well, even better. I am the same way in most cases, I am a system designer
not an algorithms person - so do what you can and I'm sure the code will
evolve _very_ fast. We just need to get to the point where it's usable and
functional so people will start using it in production.

> Anyways I also think that the pear error handling (with their error code
> abstraction) is the way to go (allthough Manuel does not quite agree there).

I disagree with him - without having seen the argument: in this case I'm
happy to flush BC down the toilet to get serious error handling in a common
framework. if you want a new building you need to knock parts out, error
handling is one of them :)

> But I guess that had to happen anyways if "metapear" was to be included into
> PEAR (which to me is the main reason for all of this).

Yep! Pear Error handling is well designed (ok I have a couple gripes) and we
should all use it :)

_a

> Have a look at Smarty 2.0 <http://phpinsider.com>.  They do this and
it
> works brilliantly (but then what else do you expect when it's coded by
> Monte and Andrei?) - they call it a plugin architecture, but I guess
you
> could call it a package architecture instead :-)

ok, I will look at it

>  >> Another question: Does "metapear" even need to be able to retrieve
> resultsets
>  >> step by step? I really do not see the advantage there. People
should
> ensure
>
> Not entirely sure what you mean, but if you're talking about the
ability
> to do:
>          while ($row = $result->fetchRow(DB_FETCHMODE_ASSOC)) {
>                  // Massage the data
>                  $data[] = $row;
>          }
>
> then I say we need this.

I am talking about fetching single cells or rows instead of the entire
result set at once

> Also, the get*() methods in PEAR-DB are really useful - I know they
add
> overhead, but for ease of programming they are brilliant.

Could someone explain to me the real advantage behind prepare?
I think I know part of it but could someone just give me an entire run
down? :-)

Lukas Smith
smith@...
_______________________________
  DybNet Internet Solutions GbR
  Alt Moabit 89
  10559 Berlin
  Germany
  Tel. : +49 30 83 22 50 00
  Fax : +49 30 83 22 50 07
  www.dybnet.de info@...
_______________________________

Hi,

do you know anything about the internals of smarty?
After briefly taking a look, it seems to me their on demand works
because they only have one function per plugin ...

But I guess we could also just maintain an array of all functions that
are in each plugin and then do a require_once when the function is
needed ...

Actually I have no good idea to do this at all ... Manuel what was your
idea again?

I guess what Stig is offering is aggregate .. but that will only work
for very recent versions of php ...

Best regards,
Lukas Smith
smith@...
_______________________________
  DybNet Internet Solutions GbR
  Alt Moabit 89
  10559 Berlin
  Germany
  Tel. : +49 30 83 22 50 00
  Fax : +49 30 83 22 50 07
  www.dybnet.de info@...
_______________________________

At 11:23 PM 3/17/02 +0100, Lukas Smith wrote:
>Hi,
>
>do you know anything about the internals of smarty?
>After briefly taking a look, it seems to me their on demand works
>because they only have one function per plugin ...

I thought that most of our database commands were only one function?

>But I guess we could also just maintain an array of all functions that
>are in each plugin and then do a require_once when the function is
>needed ...

Yes, keeping the most used functions in the original file and dynamically
loading the less used ones.

>I guess what Stig is offering is aggregate .. but that will only work
>for very recent versions of php ...

Exactly.  As an aside, does it come by default in PHP 4.1.2?

Peter.

--
Maple Design - quality web design and programming
http://www.mapledesign.co.uk

On Sun, 2002-03-17 at 21:25, Lukas Smith wrote:
>
> Could someone explain to me the real advantage behind prepare?
> I think I know part of it but could someone just give me an entire run
> down? :-)

I'll give you the ones I can think of right now.

For lazy programmers: If you don't want to bother with quoting, prepare
is really nice.  You don't have to bother about calling quote functions
etc, and ease of use is one of PEAR DB's primary goals.

Repeated queries: If you want to re-run the same INSERT over and over
just with different data, prepare lets you do that in a way that is
_much_ more efficient on the backends that have native prepare/execute
support (which is most serious databases today).  It has some overhead
on mysql & friends, but you still have the option of just using query()
if you don't care about efficiency with other backends.

Query caching: Some databases, like Oracle, have a cache of parsed and
optimized queries.  By using prepare(), the database will need to parse
and optimize your query just once instead of every time you execute it.
This can be a really big speedup.

Easy LOB handling:

$sth = $dbh->prepare("INSERT INTO files (contents) VALUES(&)");
$sth->execute(array("/tmp/file-with-contents"));

Granted, PEAR's LOB handling leaves a lot to be desired for other
backends than mysql/pgsql today, but this is the API.

  - Stig

Hello Lukas,

Sorry for the delay, I have a backlog of messages from you to reply that
I did not do before because I am working really hard to bring up tens of
mirrors world wide for the PHP Classes. I will answer to all pending
messages as soon as I have some time free.

Lukas Smith wrote:
>
> Hi,
>
> do you know anything about the internals of smarty?

No, but it does not need to look into it to figure how to make a plugin
architecture with PHP. MetaL compiler is all plugable. Despite it loads
all the classes it needs before compiling anything, there is no reason
to not make Metabase load only the necessary classes on demand.


> After briefly taking a look, it seems to me their on demand works
> because they only have one function per plugin ...
>
> But I guess we could also just maintain an array of all functions that
> are in each plugin and then do a require_once when the function is
> needed ...

If we know all functions that we need, there is no reason to keep them
in an array.


> Actually I have no good idea to do this at all ... Manuel what was your
> idea again?

Very simple: if a driver knows specifieds that it supports a feature
that is made available as an extension, it should store in some class
variable the class file name thatr should be loaded at setup time. The
drivers base class should always implements the extension functions.
When those functions are called, it should defer to the extension
object.


> I guess what Stig is offering is aggregate .. but that will only work
> for very recent versions of php ...

I have yet to see the documentation of that function, but I think that
as long as we choose a convinient function naming scheme, we should be
able to use aggregate conditionally if it exists
if(function_exists("aggregate")) .

Regards,
Manuel Lemos

Hi all,

good news
Today I applied for a CVS account and Stig promised I would get it :-)
So I will soon put metapear into the PHP CVS.

At the same time I have begun reformatting things to be more readable to
the currently complaining audience. This means I really need this to go
fast because now I will be in a world of pain with every Metabbase new
release.

I have also made some changes to the get* stuff that uptil now was
mostly just code and paste. Now those methods are much better integrated
into metapear and make heavy use of allready existing methods.

All those changes seem to be working nicely.

So the only thing that is missing before metapear can be considered
useable is completing the move to PEARs error handling. This will be a
lot of work and hopefully with metapear getting into CVS people can
start helping out with some of the actual coding.

And while they are at it they can help pearifying the code more and
more.

So anyways the next release will hopefully be in CVS.

Best regards,
Lukas Smith
smith@...
_______________________________
  DybNet Internet Solutions GbR
  Alt Moabit 89
  10559 Berlin
  Germany
  Tel. : +49 30 83 22 50 00
  Fax : +49 30 83 22 50 07
  www.dybnet.de info@...
_______________________________

Well ideally the user does not have to choose anything but only use what
method he/she pleases. I think that is the goal we are trying to
accomplish. I would even be willing to give up a little bit of
performance in order to reach that goal.

BTW: please keep these threads cross mailinglist so we all can
collaborate

Best regards,
Lukas Smith
smith@...
_______________________________
  DybNet Internet Solutions GbR
  Alt Moabit 89
  10559 Berlin
  Germany
  Tel. : +49 30 83 22 50 00
  Fax : +49 30 83 22 50 07
  www.dybnet.de info@...
_______________________________

> -----Original Message-----
> From: John Lim [mailto:heyjohnlim@...]
> Sent: Tuesday, March 19, 2002 6:31 PM
> To: pear-dev@...
> Subject: [PEAR-DEV] Re: Improving speed (long)
>
>
>
> > So IMHO the functionality could be splited in three parts:
> >
> > No Manipulation: query, get*, prep/exec, datatypes  (default)
> > Manipulation:    sequences, transactions
> > Extra:           schema managment, cache
> >
> > The "how" question is more difficult to answer :-). I see some ways:
> >
> > 1) by aggregating methods as Stig proposed (cool as it can happen
> > automaticaly but no support for almost no PHP4 installations).
> >
> > 2) by extending and preselecting the mode (will need knowledge of
what
> > is avaible in each mode but will be supported by all PHP4 releases).
> >
> > 3) by having different objects for the different modes and some kind
of
> > "object manager" to create, comunicate and handle them (no need of
> > preselecting the mode, supported by all PHP4 releases but perhaps
tricky
> > to code).
> >
> >
> > Tomas V.V.Cox
>
> Hi Tomas,
>
> Nice summary of the issues. Regarding "how":
>
> Aggregation (1) is an idea, but what about backward compat?
> Furthermore does anyone have benchmarks using it?
>
> For speed, I like (2) extending and preselecting
> using classes. Different classes in the same hierarchy could
> have different functionality. Eg.
>
> class MySQL_Primitives { }
> class MySQL_Standard extends MySQL_Primitives { }
> class MySQL_Extended extends MySQL_Standard { }
>
> The user just chooses which class to use, based on his/her
> needs.
>
> (3) I don't really see how an object manager really helps.
> The user should choose the mode, not the object manager.
>
> Regards, John
>
>
>
>
>
> --
> PEAR Development Mailing List (http://pear.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php

> The other advantage is that you don't need to quote your strings
yourself,
> avoiding any security problems from tainted data (eg. $_GET and $_POST
> strings).

Aeh how so?
I am aware of the problem of possible "tainted" data but where does the
data get handled differently from a "normal" query?

Best regards,
Lukas Smith
smith@...
_______________________________
  DybNet Internet Solutions GbR
  Alt Moabit 89
  10559 Berlin
  Germany
  Tel. : +49 30 83 22 50 00
  Fax : +49 30 83 22 50 07
  www.dybnet.de info@...
_______________________________

> -----Original Message-----
> From: John Lim [mailto:heyjohnlim@...]
> Sent: Tuesday, March 19, 2002 6:40 PM
> To: pear-dev@...
> Subject: Re: [PEAR-DEV] Re: [binarycloud-dev] FW: lets talk "metapear"
-
> politics aside:-)
>
>
> > Could someone explain to me the real advantage behind prepare?
> > I think I know part of it but could someone just give me an entire
run
> > down? :-)
> >
> > Lukas Smith
> > smith@...
>
> Hi Lukas,
>
> Prepare() parses and compiles your sql once. So if you have an insert
> statement
> that is suppose to be run 1000 times in a loop, imagine saving the
compile
> time
> by doing a Prepare() once only. It's a bit like using Zend Cache or
APC
> for
> SQL.
>
> The other advantage is that you don't need to quote your strings
yourself,
> avoiding any security problems from tainted data (eg. $_GET and $_POST
> strings).
>
> Regards, John
>
>
>
> --
> PEAR Development Mailing List (http://pear.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php

On Tue, 2002-03-19 at 18:39, Lukas Smith wrote:
> > The other advantage is that you don't need to quote your strings
> yourself,
> > avoiding any security problems from tainted data (eg. $_GET and $_POST
> > strings).
>
> Aeh how so?
> I am aware of the problem of possible "tainted" data but where does the
> data get handled differently from a "normal" query?

It is handled differently because all the right quoting is done behind
the scenes (either because the DB driver quotes for you, or because it
uses some bind mechanism).  In a normal query you need to do the quoting
yourself.

  - Stig

> > > The other advantage is that you don't need to quote your strings
> > yourself,
> > > avoiding any security problems from tainted data (eg. $_GET and
$_POST
> > > strings).
> >
> > Aeh how so?
> > I am aware of the problem of possible "tainted" data but where does
the
> > data get handled differently from a "normal" query?
>
> It is handled differently because all the right quoting is done behind
> the scenes (either because the DB driver quotes for you, or because it
> uses some bind mechanism).  In a normal query you need to do the
quoting
> yourself.

Ah well ...
You mean because you can employ different placeholders like '?' and '!'.
Well this sort of thing is a thing of the past with the inclusion of
Metabase since now you can quite easily specify what type the data is
for queries and prepared queries.

This why you truly don't have to worry about quoting etc. but only about
types.

This still does not solve the issue though, since for example some RDBMS
allow quoted integers and some don't etc.

So I still don't see where prepared queries are the solution to
"tainted" data because not all data will get quoted and therefore you
still have the danger of malicious query tampering.

Or am I missing something here?

Best regards,
Lukas Smith
smith@...
_______________________________
  DybNet Internet Solutions GbR
  Alt Moabit 89
  10559 Berlin
  Germany
  Tel. : +49 30 83 22 50 00
  Fax : +49 30 83 22 50 07
  www.dybnet.de info@...
_______________________________

On Wed, 2002-03-20 at 00:34, Lukas Smith wrote:
> > > > The other advantage is that you don't need to quote your strings
> > > yourself,
> > > > avoiding any security problems from tainted data (eg. $_GET and
> $_POST
> > > > strings).
> > >
> > > Aeh how so?
> > > I am aware of the problem of possible "tainted" data but where does
> the
> > > data get handled differently from a "normal" query?
> >
> > It is handled differently because all the right quoting is done behind
> > the scenes (either because the DB driver quotes for you, or because it
> > uses some bind mechanism).  In a normal query you need to do the
> quoting
> > yourself.
>
> Ah well ...
> You mean because you can employ different placeholders like '?' and '!'.
> Well this sort of thing is a thing of the past with the inclusion of
> Metabase since now you can quite easily specify what type the data is
> for queries and prepared queries.
>
> This why you truly don't have to worry about quoting etc. but only about
> types.
>
> This still does not solve the issue though, since for example some RDBMS
> allow quoted integers and some don't etc.
>
> So I still don't see where prepared queries are the solution to
> "tainted" data because not all data will get quoted and therefore you
> still have the danger of malicious query tampering.
>
> Or am I missing something here?

Aha!  We're misunderstanding eachother, I'm talking about escaping
special characters in data before embedding it in the query.  As for
types, yes you're right.  Today PEAR's prepare emulation puts ampersands
and escapes only string data, so you have control over that by passing
data with the right PHP types.  Ideally we should have some knowledge of
the types in the database, but I'm not sure if that is realistic.

  - Stig

> Aha!  We're misunderstanding eachother, I'm talking about escaping
> special characters in data before embedding it in the query.  As for
> types, yes you're right.  Today PEAR's prepare emulation puts
ampersands
> and escapes only string data, so you have control over that by passing
> data with the right PHP types.  Ideally we should have some knowledge
of
> the types in the database, but I'm not sure if that is realistic.

Well metabase can do both.
Metabase has internal datatypes that it maps to RDBMS specific
datatypes.
These datatypes are used for prepared queries and can also be used for
normal queries. Metabase is also aware of the escape characters for each
RDBMS.

Best regards,
Lukas Smith
smith@...
_______________________________
  DybNet Internet Solutions GbR
  Alt Moabit 89
  10559 Berlin
  Germany
  Tel. : +49 30 83 22 50 00
  Fax : +49 30 83 22 50 07
  www.dybnet.de info@...
_______________________________

On Wed, 2002-03-20 at 18:00, Lukas Smith wrote:
> > Aha!  We're misunderstanding eachother, I'm talking about escaping
> > special characters in data before embedding it in the query.  As for
> > types, yes you're right.  Today PEAR's prepare emulation puts
> ampersands
> > and escapes only string data, so you have control over that by passing
> > data with the right PHP types.  Ideally we should have some knowledge
> of
> > the types in the database, but I'm not sure if that is realistic.
>
> Well metabase can do both.
> Metabase has internal datatypes that it maps to RDBMS specific
> datatypes.
> These datatypes are used for prepared queries and can also be used for
> normal queries. Metabase is also aware of the escape characters for each
> RDBMS.

Does Metabase have this information because of the XML table definition
files, or does it retrieve it from the database?

  - Stig

It has to be provided by the user.

Lukas Smith
smith@...
_______________________________
  DybNet Internet Solutions GbR
  Alt Moabit 89
  10559 Berlin
  Germany
  Tel. : +49 30 83 22 50 00
  Fax : +49 30 83 22 50 07
  www.dybnet.de info@...
_______________________________

> -----Original Message-----
> From: Stig S. Bakken [mailto:ssb@...]
> Sent: Wednesday, March 20, 2002 7:22 PM
> To: Lukas Smith
> Cc: 'Stig S. Bakken'; 'John Lim'; pear-dev@...; metabase-
> dev@yahoogroups.com; 'binarycloud-dev'
> Subject: RE: [PEAR-DEV] Re: [binarycloud-dev] FW: lets talk
"metapear"-
> politics aside:-)
>
> On Wed, 2002-03-20 at 18:00, Lukas Smith wrote:
> > > Aha!  We're misunderstanding eachother, I'm talking about escaping
> > > special characters in data before embedding it in the query.  As
for
> > > types, yes you're right.  Today PEAR's prepare emulation puts
> > ampersands
> > > and escapes only string data, so you have control over that by
passing
> > > data with the right PHP types.  Ideally we should have some
knowledge
> > of
> > > the types in the database, but I'm not sure if that is realistic.
> >
> > Well metabase can do both.
> > Metabase has internal datatypes that it maps to RDBMS specific
> > datatypes.
> > These datatypes are used for prepared queries and can also be used
for
> > normal queries. Metabase is also aware of the escape characters for
each
> > RDBMS.
>
> Does Metabase have this information because of the XML table
definition
> files, or does it retrieve it from the database?
>
>  - Stig

>> Well metabase can do both.
>> Metabase has internal datatypes that it maps to RDBMS specific
>> datatypes.

Yes. God I love that. :)

>> These datatypes are used for prepared queries and can also be used for
>> normal queries. Metabase is also aware of the escape characters for each
>> RDBMS.
>
> Does Metabase have this information because of the XML table definition
> files, or does it retrieve it from the database?

Metabase allows a set of types:

integer, text, boolean, date, timestamp, time, float, decimal, clob, blob

those you specify in the XML.

but metabase knows for each RDBMS:
     -if that type is supported
     -how it is supported

so no matter what DMBS you use, you get back the same thing.

that is of central importance and one of the major reasons binarycloud uses
metabase.

-alex

Well currently you do something like QuerySet* (for exampple
QuerySetInteger) for every placeholder in your prepared query.

I have extended this to a method that can do this in bulk.
You just specify and array (similar to how you do it with get*).
But you not only specify the values but also the types in this array.
So this makes the process quite painless.

Metabase allready has the same bulk feature for normal queries.

Best regards,
Lukas Smith
smith@...
_______________________________
  DybNet Internet Solutions GbR
  Alt Moabit 89
  10559 Berlin
  Germany
  Tel. : +49 30 83 22 50 00
  Fax : +49 30 83 22 50 07
  www.dybnet.de info@...
_______________________________

> If the database API is not good enough to reveal the type info
required,
> I use a simple heuristic:
>
> if (! is_numeric($val)) $conn->qstr($val);
>
> eg. I only quote non-numeric variables. This normally works with dates
> because most databases accept dates as strings fortunately.

Some databaes even allow integers to be quoted (I think most opensource
RDBMS do for example)

Lukas Smith
smith@...
_______________________________
  DybNet Internet Solutions GbR
  Alt Moabit 89
  10559 Berlin
  Germany
  Tel. : +49 30 83 22 50 00
  Fax : +49 30 83 22 50 07
  www.dybnet.de info@...
_______________________________