New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

default to timestamp with time zone for oracle #876

Merged
merged 1 commit into from Jun 29, 2015

Conversation

Projects
None yet
2 participants
@vschoettke
Collaborator

vschoettke commented Jun 24, 2015

In relation to #184 I also changed the default for datetime(), timestamp(), timestamps()and time() to "timestamp with time zone" for the oracle dialect.
Like the postgres implementation, if the without param for datetime(name, [without]) or timestamp(name, [without]) is set to a truthy value then only "timestamp" is generated.

@vschoettke

This comment has been minimized.

Collaborator

vschoettke commented Jun 25, 2015

@tgriesser the code works fine but only updates the code in the src folder and the tests. I think the travis script should build the release (lib) files and then execute the tests. Currently making a pull request that breaks tests does not warn.

I would also favor getting rid of the of the lib folder/any files that are generated by the build script in the repository to avoid extra commits that just change the compiled/generated data.

tgriesser added a commit that referenced this pull request Jun 29, 2015

Merge pull request #876 from vschoettke/oracle-timestamp-with-timezone
default to timestamp with time zone for oracle

@tgriesser tgriesser merged commit a497830 into tgriesser:master Jun 29, 2015

1 check failed

continuous-integration/travis-ci/pr The Travis CI build failed
Details
@tgriesser

This comment has been minimized.

Owner

tgriesser commented Jun 29, 2015

Thanks!

I would also favor getting rid of the of the lib folder/any files that are generated by the build script in the repository to avoid extra commits that just change the compiled/generated data.

The reason I've kept them in is that it allows people to pick specific sha commit-ish as they have in the past in their package.json, rather than only relying on the npm releases.

@vschoettke

This comment has been minimized.

Collaborator

vschoettke commented Jun 30, 2015

@tgriesser If you don't update the build files every time you commit/merge, people will only get the npm releases anyways. Someone may also think a bug is fixed because it says so in the commit but it's still not fixed in the build files.

I also think the danger of merging something non-working and detecting it way later is too high.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment