Re: [Fwd: Re: [PEAR-DEV] New package proposal]

David Sanders wrote:

Just forwarding to the list in case anyone else is interested... ---8<--- Not rude at all, I appreciate the feedback. Its actually been a while since I used db_dataobjects, so off hand I don't remember ALL the problems I had with it. But I'll throw out what I remember. First, it was harder to setup. I realize there's a learning curve, but I found it unnecessarily complex. I also didn't like the cryptic files that it made. That's fine if everything works fine, but if you find a bug and need to debug it, your don't really have options. Sounds a bit surprising, - there are quite a few tutorials (other than the manual), quite easily found via google. pear-general or the irc channels can be useful as well.

DB_DataObject::debugLevel() is a good clue for debugging..

-- With mine, you only need to create one file and the setup would be the same as if you wrote the whole thing by hand. Its very easy to follow through. The most you need to look at to get to the bottom of any class is 3 files. It's quite easy to make a simpler version, but DB_DataObjects is quite well maintained, although it's release schedule could do with improving.. What you have is what DB_DataObjects was similar to over 6 years ago - It's grown alot since then (for better and worse..), and there is already a maintained alternative, DB_Table in PEAR.

At the end of the day, if you converted it to PEAR standards, you would end up with something very close to what DB_DataObject already is.

Second, when db_dataobject gets updated, the update process is confusing. Care to elaborate - it should be relatively obvious.

If you create the getColumn, setColumn variables (and then modify them for your purposes), those will be overwritten when you update the code. This should not happen - although there may have been bugs in some versions that caused that occasionally.

-- With mine, the get_column, set_column variables are created by default for all classes and can easily be overloaded: http://www.ddataobjects.com/current/prog/instructions/examples/overloading_functions.php When the code is updated, all custom modifications are saved. This can already be done, generate_setters/generate_getters options (although I never personally use them)

Also, you can add comments in the postgresql database to get some advanced features. http://www.ddataobjects.com/current/prog/instructions/setup.php#setter_comment_options This does seem a bit magical, although I dont think it would be particularly difficult to add to DB_DataObject.

Free variable checking for free http://www.ddataobjects.com/current/prog/instructions/examples/db.html This could be added to DB_DataObject although I suspect stored procedures are probably the best way to do this.

<-- see table "person" The default set_ functions will check to make sure a valid zip_code, phone_number, email, and currency are entered. Or you could put your own unique regular expression in. http://www.ddataobjects.com/current/prog/instructions/functions/set_.php (I'll admit this would probably be better in the code, but I didn't think about overloading functions until the was already added) My code also has added functions to make forms much easier to create and parse: http://www.ddataobjects.com/current/prog/instructions/functions/get_ie.php This kind of violates the separation of logic and presentation. - but not particularly difficult to do in DB_DataObject.

Also, I create the option of linking tables. Let's say you have two tables person - person_id, name, address, ... pics - pics_id, person_id, size, file, ... If you create the foreign key in pics to point to person, then when you delete person "person->delete()" it knows the tables are linked and will automatically delete the corresponding pics. probably best done using TRIGGERS in the database, I tend to find doing all of this automatically can result in some unexpected issues.. -

There are quite a few other additions over db_dataobject, but at this point I'm guessing you've made up your mind whether or not you think this is worth the trouble. So I'll stop here. You don't have to go into great detail to checkout the code, just click on a couple functions and look at the example code to see how concise this enables you to code. I've highlighted what I think some of the better features are. If it was PDO based, PHP5 only and clean, followed PEAR standards, had multiple database support etc. and followed a similar model to DB_Table or DB_DataObjects you might have a fighting chance, but I dont think this is really an advancement on where the D.O. abstraction layers are in PEAR at present.

You have come up with few 'cool' ideas - running from a url etc. that really need to be thought through as well - On the face of things it appears to be considerably more complex to understand than DB_DataObject is. - let alone debug... I would recommend even if you just want to share this and use it for your own projects, that you consider following PEAR standards, and move away from in-line scripting style. I hope the comments where not to harsh Regards Alan

As the only person that responded, I'll let you decide what to do with this. If you think it could be of benefit to the community, I'll pursue it. If not, I'll just keep working on it for myself and using it for myself. I think I've made a VERY useful product and was interested in giving back to the community, but if everyone is happy with what they have, its not a problem. Thanks for responding (and making it in this email if you did), Dan On Feb 7, 2008 8:41 PM, David Sanders <dsanders@baselinesolutions.com.au <mailto:dsanders@baselinesolutions.com.au>> wrote:

    Dan Hayes wrote:

I wrote code that is somewhat similar to db_dataobjects, but in

    my opinion,

offers numerous advantages over db_dataobjects. It currently

    only works for

postgresql (I don't think it wouldn't be that difficult to make

    it work with

mysql also), but I've documented it, and there are lots of

    options.  Its

also very easy to get up and running and to update and modify.

     I'm not sure

if this would be a good PEAR package, or if I should just continue developing it as is. Any feedback would be appreciated. http://www.ddataobjects.com

    I don't mean to be rude here but I think you need more than just a vague
    paragraph explaining why you don't want to use MDB2...  Nor have you
    even
    bothered to explain what the improvements over DB_DataObject are.
     To be frank,
    I don't think you'll get many people wasting their time sifting
    through your
    code to see if it'll be worth anything.

    --
        David Sanders
        shangxiao