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

Use sybpydb for Sybase access on Py3 #7

Merged
merged 4 commits into from
Aug 29, 2019
Merged

Use sybpydb for Sybase access on Py3 #7

merged 4 commits into from
Aug 29, 2019

Conversation

jeanconn
Copy link
Contributor

Use sybpydb for Sybase access on Py3

@@ -170,7 +174,7 @@ def fetch(self, expr, vals=None,):

:rtype: Generator that will get one row of database as dict() via next()
"""
self.execute(expr, vals)
self.execute(expr, vals, commit=False)
Copy link
Contributor Author

@jeanconn jeanconn Aug 13, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This change will apply to sqlite as well. I can code around it (make conditional for sybase), but I think it is ok? For sybase, if the "select" statement is "committed", the cursor has nothing left to do and apparently cannot return the results.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have no idea if it's OK in sqlite, but I guess if tests and ska_testr pass then we're good.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks. The Python sqlite docs suggest to me that this is a no-op difference on that side https://docs.python.org/3/library/sqlite3.html#controlling-transactions , and that if we really care we probably need to add isolation_level control to the DBI init.

@jeanconn
Copy link
Contributor Author

jeanconn commented Aug 27, 2019

With the updated flt_envs, all module tests pass on CentOS5, 6, and 7 HEAD machines.
The sybase tests are still correctly skipped on OSX (sqlite pass).

@jeanconn
Copy link
Contributor Author

I note the test are also correctly skipped on chimchim and the sqlite tests still pass.

@jeanconn jeanconn requested a review from taldcroft August 27, 2019 17:46
@taldcroft
Copy link
Member

I'm a little confused about testing because of:
https://github.com/sot/Ska.DBI/blob/0624d6df454128615f6c89ba8bf1a1053971aeb2/Ska/DBI/tests/test_dbi.py#L14

This would lead me to think that on Ska3 all sybase tests are being skipped. I was originally wondering if sybase insertion is working since the code logic would now use the sqlite syntax for a sybase insert with replace=False.

@jeanconn
Copy link
Contributor Author

jeanconn commented Aug 27, 2019

Ah. Good point. I forgot I had a testing commit that was not pushed. Though I'm not sure I follow your second sentence.

@jeanconn
Copy link
Contributor Author

Regarding replace did you want me to try to test to see if sybase now works with replace=True? I haven't tried to see if we gain any new functionality.

import os
import pytest
import numpy as np
from Ska.DBI import DBI

HAS_SYBASE = six.PY2

module = os.path.join(os.environ['SYBASE'], os.environ['SYBASE_OCS'],
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is going to raise an exception if those env vars are not defined.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point. I just tested in "production-like" environments so far so hadn't considered/noticed. Which brings up the separate point that I could use some automated testing because our requirements are becoming all combinations of CentOS 5,6,7 production, 6,7 root not production, and 6,7 non-root + OSX root and non-root, + CentOS5 32 production, + Windows whatever.

elif self.dbi == 'sybase':
if replace:
raise ValueError('Using replace=True not allowed for Sybase DBI')
colrepls = tuple('@'+x for x in cols)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The point of my other comment is that previously, calling with dbi='sybase' and replace=False would do the insert but using a different definition for colrepls and vals than used for dbi='sqlite3'. With this current code the sybase insert is done using the same syntax as for sqlite3. I was just wondering if that actually works now (API change in the DB interface?).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, it isn't really an API change in the interface because this is a different interface, but my assumption was yes. And apologies it took me a bit to catch up as I thought you'd already seen the code simplification.

I largely just fiddled until manual unit tests and the existing tests passed, so didn't much reference the docs. So if our insert tests are not sufficient across data types or the like we may end up with errors later.

When you say "actually works now" I didn't think that we'd get test passing without it working, though when I was fiddling with inserts I did use sqsh to eyeball the test db and confirmed stuff was getting into it.

@jeanconn
Copy link
Contributor Author

Thanks again for the catch on the env vars issue. I just set it to check for the SYBASE_OCS variable first before looking for the module path (built from env vars) in the latest commit.

I did decide that checking for SYBASE_OCS was sufficient (and am not checking for SYBASE, SYBASE_OCS, and correct LD_LIBRARY_PATH in the test Ska.DBI.DBI). If the user has SYBASE_OCS set but not SYBASE, that's on them.

@taldcroft
Copy link
Member

Sounds fine.

@jeanconn jeanconn merged commit 618c8dd into master Aug 29, 2019
@jeanconn jeanconn deleted the sybase branch August 29, 2019 17:46
@jeanconn
Copy link
Contributor Author

My thought was that at least #11 and possibly #12 could go in a Ska.DBI release with this (maybe release 4.0?).

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.

2 participants