Re: [PROPOSAL] DB_Simple

Hi! My problem with this package is "simple", too: I don't see the problem it is trying to solve. The only *new* functionality is checking the field types, but: 1) Database does this anyway and does this better. 2) There can be other constraints defined inside database that can raise an error, even if the types match. 3) The package requires describing the table structure *twice*: first when you create it and then when you are using "DB_Simple". "DB_Simple" does not provide a tool to extract the metadata from the DB (DB_DataObject does). This can lead to inconsistencies. Of course, with MySQL that considers 2003-02-31 a valid date and does not understand CHECK constraints another application level check can come in handy [1]. That's why I will not oppose the package only if it is moved to MySQL namespace ghetto. And, last but not least, let me quote The Holy PEAR Manual[2]: ------------------------------------------------------------------------ First of all, do a reality check: Why do I want to commit a new package? Really bad answers are "To see my name in PEAR" or "I didn't understand the API of the existing class". A good reason for a new class is often, that you are missing a function, behaviour or speed in an existing implementation. In this case, you should take a look at this class, if it possible to extend this class. If not, then you have a good reason to commit a new class. "If not" means, it isn't possible to add the required functionality without changing the basics of this class. ------------------------------------------------------------------------ [1] http://sql-info.de/mysql/gotchas.html [2] http://pear.php.net/manual/en/faq.competitive-packages.php Paul M Jones wrote:

- DB_SIMPLE_INTNOSIGN

     unsigned long integer, typcially BIGINT UNSIGNED

MySQLism?

No, each supported database uses its own internal datatypes for numbers and strings; I call the MySQL example is "typical" only because it's typical for me, although MS-SQL is looming in my future.

I meant 'unsigned' modifier itself is a MySQLism. I doubt that it is supported by any other database.

Quoting the comment buried *deep* inside createTable(): // add the field definition ... // mysql only for now, include others later If the package supports only MySQL, then it has to have MySQL in its name.

I should have removed the comment; it is not MySQL only, although I have not tested it on others. Please note the class property $_declare; it has field declaration keywords for a number of different databases.

Ugh. Looked more closely at the method: is it intentional that it uses DB_SIMPLE_STRING for all date and time related columns???

Is this any easier than to directly write SELECT id, username, email FROM tablename WHERE division = 'Information Technology' ORDERB BY username The manually written query has less chars in it, BTW.

One might ask the same thing about DB_DataObjects, and the answer is "yes and no." Maybe I am not a good SQL guy; sometimes I want a baseline list, and sometimes I want to filter that baseline list. Having a basic query as a property, and then adding a different filter to it in different methods, has been useful to me in the past.

OK, you may have a point here. But I think we already have some query builders in PEAR?

=========================================== Automated INSERT and UPDATE With Validation -------------------------------------------

...

Will it also check for column constraints, foreign keys and the like? Besides, this info is *not* read from DB, but provided by the user -> inconsistencies.

No, at least not yet -- do all the supported databases use all those features? I have tried to find the common denominators between the supported databases and abstract them, but it's possible I missed some.

I think all major databases except MySQL support column constraints. And even MySQL sorta supports foreign keys. My real point being, of course, that this stuff should be checked in DB, not in application.

And my all-time favourite error message, from delete() method: return $this->raiseError("The WHERE clause in your DELETE " .

    "statement has no operator (=, <, <=, >, >=, LIKE) in it; " .
    "this might delete all records.  Request denied.");

Seriously, I've stupidly sent "DELETE FROM table" commands before, and that only little bit of code would haved save my but at least once.

A 'ROLLBACK' command seems a better choice in this case. ;]

BTW, what about DELETE FROM tablename WHERE 1 = 1?

Then you're asking for it, and so it's OK.

What about DELETE FROM tablename WHERE id IN (1, 2, 3) DELETE FROM tablename WHERE username ~ '^Paul'; -- PostgreSQL regex check (Hint: an error)