On Fri, Feb 25, 2005 at 02:05:10PM +1000, David Whyte wrote: > I think the major issue is having two copies of the queries. All > clients will need to be updated if a performance enhancement or table > change were made. > > IMO it is much easier to ask for the data, and know just the format of > the data that is being returned.
If a major change is made to the data yes. But most changes should be of the form where the tables are expanded, and the old queries, which name the specific columns they are fetching, should still work fine. It is true that if you had another layer interpreting the data the backend would be free to change the meanings of fields because it can reinterpret them for older clients, but that comes at a cost of course. But you also get a sitatuation where, if a client wants to get data, it can only get data the backend knows to serve it -- or it has to go and do SQL queries itself, the thing you wanted to avoid, and is subject, in those areas, to dealing with changes. This is a tough call, there are merits either way. Extra levels of abstraction do have uses, and can make code more portable and resistent to version change problems. At a cost of coding time. And it is true that for some queries (notably the scheduler ones) the clients of course are already going through the backend. That presents its own problems because the current protocol has custom serializers and deserializers. (This is one thing Java helps a lot with, even if you don't like java's serializer the reflection makes it easy to write your own generalized serializers.) This approach would also suggest that if you are coding a frontend and you want to query some data, the right way to do it is to write the query in the backend and add protocol stuff so the frontend can ask the backend to do the query. Not only might this be more work on its face, the frontend probably also has lots of fancy libraries for dealing with sql queries and now has to make a new system.
_______________________________________________ mythtv-dev mailing list [email protected] http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
