On Fri, Jan 28, 2011 at 1:24 PM, Stephan Beal <[email protected]> wrote: > 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. >
I didn't mean to imply there were no cases where it's necessary, just that for "rational" code, it shouldn't be. :) > > 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. > True enough. I like sort() for that purpose. :) > > 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. > Absolutely. I hope I wasn't coming off as belligerent. I like the half-way compromise. -B _______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
