Re: Re: DB_Table: Summary and Pre-Call

Hi Paul,

In the one application I need 100% portability,

Here's where I'm coming from: when I write code, I *expect* to share it with others. Maybe it's smart, maybe it's dumb, but my default stance is that my code will end up in other hands on other systems, and I write it with that in mind (extensive inline comments, code standards, naming conventions, portable SQL, etc). In a sense, then, *all* of my applications require 100% portability. Does that limit me? Yes, in some ways. Does it have benefits of its own? Also yes. :-) I prefer that tradeoff; it might not be preferred by others.

I wanted to suggest an alternative POV here. I think we'd all agree on the idea that you want to build a tool that you can distribute -- and that ideally will run w/o modification on various platforms. I think we differ in how we see that accomplished, though. I see two approaches: (1) You make your app aware of differences and you handle those during an install or "build" on the clientside and (2) you simplify your app to the point where everything is very basic & there's no room for difference. Tools like MDB[2?] and Propel (and others) operate on model (1), while DB_Table follows an approach more like (2). (Correct me if I'm wrong). I think there are pros and cons to both. Your approach will work out-of-the box, but by simplifying things to such a degree you are creating DB code that doesn't talk well w/ other applications (as already mentioned). The build approach requires more work on the other end, but should produce results that are tailored (as much as possible) to the native way of doing things in an RDBSMS. In varying degrees with MDB, Metabase / Metastorage, or Propel you can distribute abstract XML that will create the specifics for your platform. I like the second option, because I've just run into too many problems in the past when I've tried to find that lowest-common denominator. It just keeps getting lower & lower the more systems you try to support. Anyway, it's possible that by eliminating native dates/times you have attained a pretty low-level SQL requirement. On the other hand, as soon as someone needs complex queries it's gonna become DB-specific pretty quickly. You'd be amazed at how simple SQL can fail to translate from one RDBMS to another (e.g. MySQL is very lax about JOINs, columns in GROUP BY being included in the SELECT statement, functions in ORDER BY, etc.). Anyway, different target audiences, perhaps. Either way, I think it should be an option, so I hope that it gets into PEAR. Good luck in the voting! Cheers, Hans