RE: [PEAR] MDB questions

Sorry since i do not read pear-general someone else had to tell me that there was a question on pear-general about MDB. > Date: Fri, 27 Sep 2002 12:56:23 +0200 > From: Lorenzo Alberton <l.alberton@studenti.to.it> > > First of all, I MUST praise all MDB developers for such an interesting > concept. > The true portability seems now a lot more feasible. > I started playing with this tool only yesterday, but it's a while since > I've followed it. Great, nice to hear. > I have some questions, though... > > 1) When setting default values in our dbschema.xml, should we quote text > > fields? > I mean: if I have sth like > > <field> > <name>pattern</name> > <type>text</type> > <length>16</length> > <default>abcdefghilmnop</default> > <notnull>1</notnull> > </field> > > should I write > <default>"abcdefghilmnop"</default> > instead? No you do not need to quote data. > > 2) What happens to "text" fields with a length inferior to the one > specified in the schema? > Are they space-padded? In particular, how are we supposed to declare > > "varchar" fields? > And what are the size limits of a "text" field? I mean, should we > consider it like a mysql's > "text", or "tinytext", or what? Yes, I've read the manual, but > I'd > like > to know what specific > mysql datatype matched the "text" MDB datatype... > They are "CHAR"s. The various TEXT datatypes are used for Character LOBs > 3) Do you plan to add a "set" or "enum" datatype? How can we > "emulate" > it > in the meanwhile? I have talked to the inventor of the schema format (Manuel Lemos) and he said that these types are hard to abstract for all RDBMS. Also you can either use a Text field or an Integer field to get the same result. The Text field will require the fewest changes to your code. Also there is the Boolean field which should cover what most people use enum's for. > 4) Is current CVS' MDB_Frontend supposed to work already? > I tried it under winXP,Apache2,Mysql,PHP4.2.3 and I always get a > blank > page after the login. Hmm I once tested a slightly more functional version. But the MDB_frontend is hanging in a bit of "limbo" atm. I need to make some drastic changes to the manager. I have written a little abstract (http://lists.php.net/article.php?group=php.pear.dev&article=8951) on the why's and how's but have not received much feedback. I hope to have some time for MDB over the course of this month. > 5) I tried some queries with MDB, and all worked fine for one-row > results. > On the other hand, while looping thru a multi-row result I could > only > fetch the first row. > I checked the sources, then I think I found the problem: in fetch* > methods (MDB/common.php) > there's this check: > if (!$this->options['autofree'] && $res != NULL) { > $this->freeResult($result); } > Is this the wanted behaviour? I mean, it's a little bit > counter-intuitive this behaviour for the 'autofree' option... > I tried setting "$db->setOption('autofree',true);" and all worked > fine. > But IMHO a result should be automatically > freed only if autofree is set to true, not the opposite... > So (IMVHO) the check should be: > if ($this->options['autofree'] && $res != NULL) { > $this->freeResult($result); } > Just my 2 cents... will take a look. I mostly use the bulk fetching method so that may be the reason why this has slipped by me. > 6) I read somewhere that you (Lukas) stated that MDB methods are pretty > much the same as PearDB... > But the conversion between the 2 isn't really painless... The > biggest > difference I noticed regards the fetch* methods. > In fact, while with PearDB I used the sintax "$result->fetch*()", > with > MDB I had to use "$db->fetch*($result)". > Yeah, that's not so terrible, but shouldn't be a common API > desirable? > I already coded a lot of work using PearDB, and I look forward to > anything that could make the switch to MDB easier... > Yes this ist he one area where I will not follow PEAR DB. Pear DB creates an object to handle result sets. This was done to allow for all sorts of funky stuff that appearently too few people used to make the performance overhead worth while. That's why it was decided to drop this feature. This obviously means that the result you get is not an object anymore but a ressource handle. This ressource handle then needs to be passed to an MDB method. Regards, Lukas