On Fri, Jan 28, 2011 at 10:16 PM, Brian Smith <[email protected]> wrote:
> My point in all this being that having the column list seems > unnecessary. Adding in output for a small > minority of users/usecases doesn't seem worth while. Even if that > output will be trivially compressed anyway. > > Being pedantic, > i understand with your reasoning, and don't feel that you are fundamentally off base. My experience has shown me, though, that there is always that odd use case where we want to know row orders precisely. The past 6 weeks i've been porting a commercial variant of the Nagios monitoring project from MySQL to a db abstraction layer for using MySQL + Oracle, and i actually found places where i needed the proper order for some of the code automation to work properly. Generic algorithms, e.g. which display tabular data in HTML, will want the headers to be stable across JSON implementations, and without the column list they might display data with column different ordering depending on the underlying JSON impl. How about we agree on leaving the column names and the rows will be in "fat" structure? For those who must do things in a certain order, they can traverse each row's properties using the keys from the "columns" list. Those who don't care (granted, 98+% of cases) can ignore it. -- ----- stephan beal http://wanderinghorse.net/home/stephan/
_______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
