From: Bob T <bo...@el...> - 2002-10-20 03:04:32
|
-1 on this I think a sequence number, when used as an ID, should be called only once, and then thrown away even if it is not used. It may not be a huge coding problem, but it could lead to a huge error, if someones private data was exposed to someone else. Why take the risk? If you have grabbed a number and then released it, why return it? It costs nothing. There are lots of numbers. What about if the number 6 is returned and the high number is already 15? Will the sequence function find 6 and use it again? It would be lots of overhead to find the blank spots, and for what reason? Re: "For example, if we add 1, 2, and 3 and then 3 is deleted, auto_increment will add 4. Our new functionality will add 3 instead (it doesn't keep track of that stuff). Possible problem? Only if a module developer did not remove all linked material. In other words, a module could have 3 as a linked id because it did not know it was deleted. So it would pull 3's data. Not a huge problem, but one we would have to be wary of while programming. |
From: Adam M. <ad...@tu...> - 2002-10-20 16:40:57
|
Sorry I took so long to join in this thread. Weekend and all :) We currently have the pear database package in place. I think it would be good for us in the long run if we rewrite a bit of code and implement more of it's features. In the process this will fix the database abstraction problem. This could also mean a change in how modules create their tables (easy dump edit), but we can retain most of the current API which should minimize editing module code. Thoughts? Adam --------------------------------- Adam Morton Developer - Web Technology Group Appalachian State University http://phpwebsite.appstate.edu |
From: Adam M. <ad...@tu...> - 2002-10-20 16:46:31
|
We may want to look at the DB_DataObject package too. It looks pretty nice. http://pear.php.net/manual/en/packages.database.db-dataobject.php Adam > Sorry I took so long to join in this thread. Weekend and all :) > > We currently have the pear database package in place. I think it would > be good for us in the long run if we rewrite a bit of code and implement > more of it's features. In the process this will fix the database > abstraction problem. This could also mean a change in how modules > create their tables (easy dump edit), but we can retain most of the > current API which should minimize editing module code. > > Thoughts? > > Adam > > --------------------------------- > Adam Morton > Developer - Web Technology Group > Appalachian State University > http://phpwebsite.appstate.edu > > > > > ------------------------------------------------------- > This sf.net email is sponsored by: > Access Your PC Securely with GoToMyPC. Try Free Now > https://www.gotomypc.com/s/OSND/DD > _______________________________________________ > Phpwebsite-developers mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpwebsite-developers --------------------------------- Adam Morton Developer - Web Technology Group Appalachian State University http://phpwebsite.appstate.edu |
From: Matthew M. <ma...@tu...> - 2002-10-20 21:00:12
|
> Sorry I took so long to join in this thread. Weekend and all :) > > We currently have the pear database package in place. I think it would > be good for us in the long run if we rewrite a bit of code and implement > more of it's features. In the process this will fix the database > abstraction problem. This could also mean a change in how modules > create their tables (easy dump edit), but we can retain most of the > current API which should minimize editing module code. > > Thoughts? > No problems rewriting but only if it simplifies the current structure. The PEAR database package appears to be tool that stack on top of the DB class, which is the same thing we are doing, just in a different format. Looking at the PEAR package, it appears to ramp up difficulty to access the database. You have to create a new database class for each table, extend it to the PEAR package, define the table. Once you do all this, it does perform some neat tricks in that you can call rows with just the id, then edit the object itself. This could clean up code as it would separate the database data from the execution. For example, if you run the aforementioned sequence through testObject you will see that it is simply pulling the highest id number and incrementing it by one right before it inserts the row. This is exactly what sqlInsert does now. It appears to use the sequence functionality we would need to implement the entire database package. I'm not sure yet. I will need to test it personally before I give a thumbs up on rewriting the Database class so close to release. Matthew McNaney Internet Systems Architect Electronic Student Services Email: ma...@tu... URL: http://phpwebsite.appstate.edu Phone: 828-262-6493 ICQ: 141057403 |