RE: [PEAR-DEV] Re: [PEPr] Proposal for Database::DB_Table

> From: Paul M Jones [mailto:pmjones@ciaweb.net] > Sent: Wednesday, January 07, 2004 11:46 PM > >> DB_Table wants above all for the data itself to be portable across > >> databases, not just the API calls. In a way, DB_Table proceeds > >> similarly to MDB in this case: it retreats to the lowest common > >> denominator in the name of portability. > > > > Well, the problem is that 4-byte integer is *a bit* lower than the > > lowest common denominator... > > This could be my mis-reading of the Unix timestamp standard (such as it > is). My understanding was that a Unix timestamp is represented by a > signed 4-byte integer (i.e., -2^31 to +2^31 -1). The DB_Table > timestamp datatype is for Unix timestamps, which seems to me a > reasonable lowest common denominator for time stamps given the wide > range of RDBMSes. > > If it is the name that throws one off, I could change it to, say, > DB_TABLE_UNIXTIME or something like that to make it more clear this is > a Unix timestamp type and not some other timestamp type. Yeah definitely call it DB_TABLE_UNIXTIME then. However I don't quite understand why you feel this solution is necessary. Actually for all but LOB's you could easily use the new datatype set of classes in MDB2 for datatype handling. The reason you are getting opposition is that DB_Table (DB_Simple) imho are needlessly "limited". I think they do offer value that isn't readily available in PEAR atm. However I see them as too limited in too many scenarios. A lot of the value comes from the "ease of use". However I can already see users of DB_Table clamouring for new features and soon it will be just as complex as a solution based on DataObject and we will probably end up with each package approaching the others feature sets. So where does that leave us? Either we say go ahead. Add the package and go down the route I described above. Or we say no and thereby turn down a package based on what will happen in the future (without giving a timeframe when). Or maybe there is a third option. Maybe Paul can fit his stuff into DB_Storage while maintaining BC. This would breath new life into code that was left to bitrot more or less. It also means that as we move to the future we can learn from the ideas there. To me I see DB reaching its end of life in terms of features. Daniel is doing a great job of really cleaning up the current feature set and making things work in all the drivers. But with php5 and pdo lurking around the corner (thereby eliminating the main two reasons for using DB, atleast for php5 - uniform API and OO interface) and MDB2 offering more features in a faster package. So all in all from a roadmap perspective I feel the way to go is this: - scratch the current itch with a simple straight forward solution as Paul is proposing (details still up for discussion) and make this part of PEAR::DB (ideally fitting this into DB_Stotage) - fix up PEAR::DB, maintain it actively but stop adding features - come up with a concept for a php5 only pdo based PEAR::DB_2 which will be based in PEAR::MDB2 - create DB_Schema - create a new DataObject which can work with either MDB2 or DB_2 Regards, Lukas