-
Notifications
You must be signed in to change notification settings - Fork 115
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
Testing Opaleye without a live DB connection? #308
Comments
incorrect DB (de)serialisation code
Can you show me some examples of such code?
|
The code given below assumes that a certain set of fields will be present in the HSTORE. However, since I'm talking to a legacy DB, there is another app that is actually populating the HSTORE. I want to be able to take the HSTORE string representations for a 100 rows from the production DB and ensure each of them roundtrips properly.
Second problem: I have two versions of the
|
I'm still not really sure what you are trying to test. Are you trying to test that creating a |
|
Yes, I understand you say you are trying to test "round-trip of Opaleye instances", but I don't get exactly what that means to you. Please can you answer the question I asked before: "Are you trying to test that creating a |
For example, are you using something like
and then checking that |
That's part 1. Part 2 is taking existing values from the production DB in some form (say, text file), which may NOT have been originally inserted via Opaleye. Trying to get Opaleye to read/parse these values and ensuring that a valid |
Part 1 seems like it's testing two things: a. That Opaleye writes and reads round trip properly You probably don't need to test b! Why not skip the "saving to the DB" part and just do:
I'm not sure what you mean in Part 2. If the values already exist in the DB how and why did they get into a text file? What does it mean to get Opaleye to read/parse something from a text file? |
This issue looks stale so I'm closing it. Feel free to reopen if necessary. |
Most of the runtime errors with Opaleye are related to either misnamed tables/columns or incorrect DB (de)serialisation code. The former definitely needs a live DB connection to test, but is is possible to check the latter without a DB connection?
If I have a bunch of text files, which contain column values from the production DB, that Opaleye should be able to work with. Can I "feed" them to opaleye in such a way that it covers the maximum surface area without involving the DB?
Is this an Opaleye concern or is it really a pg-simple concern?
The text was updated successfully, but these errors were encountered: