Skip to content
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

vschoettke
Copy link
Collaborator

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
Copy link
Collaborator Author

@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
default to timestamp with time zone for oracle
@tgriesser tgriesser merged commit a497830 into knex:master Jun 29, 2015
@tgriesser
Copy link
Member

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
Copy link
Collaborator Author

@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
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants