How changing two lines of code can take several days
I wonder if anyone else believes that the work of the developer can be measured by the number of lines of code? Let's try together to debunk this old, like the world, myth with its red eyes.
Is it difficult to change two lines of code?
The hero of this story is the open source H2 database project of a popular relational database for tests, a web console for SQL, and even contains an analogue of LevelDB / Berkeley DB Java Edition / SQLite 3 inside. An excellent project, used many times during its practice and there were no problems. Until I tried to use it with the redshift jdbc driver.
')
There is such a database in AWS, Redshift - fork of the times PostgreSQL 8.0.2 . Somewhere in the same decade, his competitor greenplum-db appeared ... Despite the fact that this database has a massively parallel architecture, and other “buns” of a column-oriented DBMS, working with it does not leave the feeling that you are in a computer history museum . I realized that this feeling was for a reason when I discovered that the drivers of the modern PostgreSQL 9.6 and Redshift driver of the fossil wire protocol postgresql 8.x conflict with the application.
I discovered that PG wire protocol 8.x is used when I connected to PostgreSQL 9.6 in the H2 web console. The results upset me and I began to understand how this could happen. Debugging led to the line receiving the connection :
It seems that everything looks according to the specification, since it is not JNDI and not javax.sql.DataSource.
Get down deeper in DriverManager. There, everything is already known and expected. In its static initialization block, the ServiceLoader is used to load the implementers of java.sql.Driver and declare this with the help of the record about the implementation of META-INF / services / java.sql.Driver in its jar. This abolished the use of Class.forName (driver) quite a long time ago - so all modern drivers are loaded without this fossil call. Nothing new for me here .
When requesting a connection, the drivers get over in the order they registered in the registeredDrivers field. DriverManager for each of them on a chain causes driver.connect (url, info). If a particular driver returned a database connection object, return it from a function. The first who handled the connection URL from the driver chain wins!
The driver itself analyzes whether it can process the jdbc: subprotocol subprotocol . To my misfortune, the redshift jdbc driver processed besides its “redshift” also “postgresql”, but with the help of the ancient code of the epoch of the mid-2000s. Clearly, the connection url request will never reach the postgres 9.6 driver.
One plus in karma to the developers of redshift jdbc - thanks though, the classes of the ancient PG implementation were hidden in a separate package, but did not leave to conflict with org.postgresql.Driver in jar hell . I tried to use their more “fresh” driver, but it did not work inside the spring boot executable jar, since dependencies were packed with “matryoshka” in it - jar'y dependencies inside the jar driver.
At the same time, the HikariCP connection pool correctly creates a new postgresql driver, unlike the H2 console. Since the user has specified a driverClass, then he is on it and calls connect without relying on DriverManager. It works in hell, caused by redshift jdbc. The reason was found quickly and it became clear how to solve the problem.
The patch was created on the weekend and sent as a pull request to the project repository, at the same time created a request for an error . After that, the correspondence and the reasoning of the change for the contributor, the second most active in the h2database repository, began. Fulfilled all his requirements and comments for this pull request and changes to the main project code. It took a lot of free time because of the two lines of change and the redshift driver. But there was already excitement and a matter of principle - to survive in a world where the fossil protocol covers the modern one. Thank you for your time, for getting into this problem. I believe that meticulousness when accepting a pull request in a popular open source project benefits quality. Almost two days off, until two lines to fix the bug appeared in the project.
Another pull request for a new functionality in schemaspy has been hanging for more than a week. It is my own fault, the problem is that I developed it on linux, and did not work on the windows system. I repent that I did not test it right away.
Share how a few lines of code absorbed time. Are there intriguing stories and detective stories?
Is it difficult to change two lines of code?
The hero of this story is the open source H2 database project of a popular relational database for tests, a web console for SQL, and even contains an analogue of LevelDB / Berkeley DB Java Edition / SQLite 3 inside. An excellent project, used many times during its practice and there were no problems. Until I tried to use it with the redshift jdbc driver.
')
There is such a database in AWS, Redshift - fork of the times PostgreSQL 8.0.2 . Somewhere in the same decade, his competitor greenplum-db appeared ... Despite the fact that this database has a massively parallel architecture, and other “buns” of a column-oriented DBMS, working with it does not leave the feeling that you are in a computer history museum . I realized that this feeling was for a reason when I discovered that the drivers of the modern PostgreSQL 9.6 and Redshift driver of the fossil wire protocol postgresql 8.x conflict with the application.
I discovered that PG wire protocol 8.x is used when I connected to PostgreSQL 9.6 in the H2 web console. The results upset me and I began to understand how this could happen. Debugging led to the line receiving the connection :
DriverManager.getConnection(url, prop); It seems that everything looks according to the specification, since it is not JNDI and not javax.sql.DataSource.
Get down deeper in DriverManager. There, everything is already known and expected. In its static initialization block, the ServiceLoader is used to load the implementers of java.sql.Driver and declare this with the help of the record about the implementation of META-INF / services / java.sql.Driver in its jar. This abolished the use of Class.forName (driver) quite a long time ago - so all modern drivers are loaded without this fossil call. Nothing new for me here .
When requesting a connection, the drivers get over in the order they registered in the registeredDrivers field. DriverManager for each of them on a chain causes driver.connect (url, info). If a particular driver returned a database connection object, return it from a function. The first who handled the connection URL from the driver chain wins!
The driver itself analyzes whether it can process the jdbc: subprotocol subprotocol . To my misfortune, the redshift jdbc driver processed besides its “redshift” also “postgresql”, but with the help of the ancient code of the epoch of the mid-2000s. Clearly, the connection url request will never reach the postgres 9.6 driver.
One plus in karma to the developers of redshift jdbc - thanks though, the classes of the ancient PG implementation were hidden in a separate package, but did not leave to conflict with org.postgresql.Driver in jar hell . I tried to use their more “fresh” driver, but it did not work inside the spring boot executable jar, since dependencies were packed with “matryoshka” in it - jar'y dependencies inside the jar driver.
At the same time, the HikariCP connection pool correctly creates a new postgresql driver, unlike the H2 console. Since the user has specified a driverClass, then he is on it and calls connect without relying on DriverManager. It works in hell, caused by redshift jdbc. The reason was found quickly and it became clear how to solve the problem.
The patch was created on the weekend and sent as a pull request to the project repository, at the same time created a request for an error . After that, the correspondence and the reasoning of the change for the contributor, the second most active in the h2database repository, began. Fulfilled all his requirements and comments for this pull request and changes to the main project code. It took a lot of free time because of the two lines of change and the redshift driver. But there was already excitement and a matter of principle - to survive in a world where the fossil protocol covers the modern one. Thank you for your time, for getting into this problem. I believe that meticulousness when accepting a pull request in a popular open source project benefits quality. Almost two days off, until two lines to fix the bug appeared in the project.
Another pull request for a new functionality in schemaspy has been hanging for more than a week. It is my own fault, the problem is that I developed it on linux, and did not work on the windows system. I repent that I did not test it right away.
Share how a few lines of code absorbed time. Are there intriguing stories and detective stories?
Source: https://habr.com/ru/post/345542/
All Articles