Going through my notes I noticed that we agreed to depricate the extra arguments to Stdio.read_file() to make way for a charset aware version in Pike 8. This has not been done.
I suppose we don't really have to. The second argument will be a string or and object in the new charser version, in contrast to the current int.
Opinions?
Now that the syntax is(/should be) there, please deprecate the extra argument.
Why is this affected_rows() part of the connection class of a database, and not part of the result class (where it belongs, IMO)?
A wild guess says it was easier to design (for a loose intepretation of "design") it that way when query() is a vehicle for not both read and write, and was defined to yield raw data only output rather than something we could attach methods to.
Johan Sundstr?m (Achtung Liebe!) @ Pike (-) developers forum wrote:
A wild guess says it was easier to design (for a loose intepretation of "design") it that way when query() is a vehicle for not both read and write, and was defined to yield raw data only output rather than something we could attach methods to.
Well, then, maybe, the "design" is flawed. affected_rows is a value that is obtained at the end of a query, so it is local to a query. If you have 2 query result sets, then having that value for each result set privatly seems more correct.
I merely offered a guess in response to the phrasing of your question.
If there is a result class, it would seem appropriate to improve it to do that too. I only recalled query results in array(mapping) form, and assumed it might have been difficult to augment that with meta info.
Johan Sundstr?m (Achtung Liebe!) @ Pike (-) developers forum wrote:
If there is a result class, it would seem appropriate to improve it to do that too. I only recalled query results in array(mapping) form, and assumed it might have been difficult to augment that with meta info.
True. In which case it would be appropriate to move the method to the result class on the lower level, and copy it into the Sql.Sql class on the higher level.
I.e. the result class that is returned with big_query can carry the method quite easily (and that's where it should be).
There is probably a good idea to think about how a new Sql database API would look like. Preferably one where database implementations are realized by inherting a base class, instead of having Sql.Sql acting as a proxy object.
pike-devel@lists.lysator.liu.se
-
Johan Sundstr�m (Achtung Liebe!) ＠ Pike (-) developers forum -
Martin Nilsson (Opera Mini - AFK!) ＠ Pike (-) developers forum
-
Peter Bortas ＠ Pike developers forum
-
Stephen R. van den Berg