CHAR(1) is treated as bool, looses information about ora HOT 11 CLOSED

How would you handle Go bool values by default?

from ora.

A bool is ok, but don't treat CHAR(1) columns as bool by default.

from ora.

That's fine if you'd like to change the default char(1) behavior.
On Apr 18, 2016 10:14 AM, "Tamás Gulácsi" [email protected] wrote:

A bool is ok, but don't treat CHAR(1) columns as bool by default.

—
You are receiving this because you were assigned.
Reply to this email directly or view it on GitHub
#82 (comment)

from ora.

Ok, thanks!

from ora.

Would this be a breaking change for some? Do we need a new version for
gopkg.in?
On Apr 18, 2016 11:49 AM, "Tamás Gulácsi" [email protected] wrote:

Closed #82 #82.

—
You are receiving this because you were assigned.
Reply to this email directly or view it on GitHub
#82 (comment)

from ora.

That's a good question. API per se does not change, "just" the defaults.
But if we didn't created a new version for the ora.N change (OCINum instead of string), then this wouldn't need a new version, either.

from ora.

Ya.

What do you think of golang's 'vendoring' feature?
Does that replace the need for gopkg.in?
On Apr 18, 2016 12:03 PM, "Tamás Gulácsi" [email protected] wrote:

That's a good question. API per se does not change, "just" the defaults.
But if we didn't created a new version for the ora.N change (OCINum
instead of string), then this wouldn't need a new version, either.

—
You are receiving this because you were assigned.
Reply to this email directly or view it on GitHub
#82 (comment)

from ora.

Yes and no. With gopkg.in, we swear that we won't change the API in the same major version; with vendoring, users can hedge against changes.
I think as a library writer, you don't need vendoring; as a library user/consumer, you want it very much.

Do we have any non-standard dependency in ora? go list -f '{{range .Imports}}{{println . }}{{end}}' lists only gopkg.in/rana/ora.v3/num which is a subpackage - already vendored in.

from ora.

The main Ora package just use the standard library. The logging bits use
other go libraries
On Apr 18, 2016 12:58 PM, "Tamás Gulácsi" [email protected] wrote:

Yes and no. With gopkg.in, we swear that we won't change the API in the
same major version; with vendoring, users can hedge against changes.
I think as a library writer, you don't need vendoring; as a library
user/consumer, you want it very much.

Do we have any non-standard dependency in ora? go list -f '{{range
.Imports}}{{println . }}{{end}}' lists only gopkg.in/rana/ora.v3/num which
is a subpackage - already vendored in.

—
You are receiving this because you were assigned.

Reply to this email directly or view it on GitHub
#82 (comment)

from ora.

Logging: I agree with Dave Cheney that a Debug and an Info level is adequate - maybe for a library, Debug is enough, as errors are reported back, and should contain enough info to localize them anyway.

The main idea I've read I cannot find now: in a library, logging should be through global settable vars - such as

var Debug func(string, ...interface{})

so the library user can provide and use any kind of logger she wishes, just provide a proper function!

from ora.

Nice!
I love the blog post and idea of offering Debug func and Info func.
Were you thinking of adding Debug func and Info func?
On Apr 18, 2016 9:54 PM, "Tamás Gulácsi" [email protected] wrote:

Logging: I agree with Dave Cheney
http://dave.cheney.net/2015/11/05/lets-talk-about-logging that a Debug
and an Info level is adequate - maybe for a library, Debug is enough, as
errors are reported back, and should contain enough info to localize them
anyway.

The main idea I've read I cannot find now: in a library, logging should be
through global settable vars - such as

var Debug func(string, ...interface{})

so the library user can provide and use any kind of logger she wishes,
just provide a proper function!

—
You are receiving this because you were assigned.
Reply to this email directly or view it on GitHub
#82 (comment)

from ora.