Skip to content

Conversation

@Nikul-OSI
Copy link

No description provided.

@Nikul-OSI Nikul-OSI mentioned this pull request Nov 3, 2025
13 tasks
@Nikul-OSI Nikul-OSI force-pushed the 18_mig_base_external_dbsource_mssql branch from dd1f2d0 to 75cb4b1 Compare November 6, 2025 08:06
@max3903
Copy link
Member

max3903 commented Nov 8, 2025

/ocabot migration base_external_dbsource_mssql

@OCA-git-bot OCA-git-bot added this to the 18.0 milestone Nov 8, 2025
@Nikul-OSI Nikul-OSI force-pushed the 18_mig_base_external_dbsource_mssql branch from ccefb71 to c33bed8 Compare November 10, 2025 09:54
@dreispt
Copy link
Member

dreispt commented Nov 10, 2025

@Nikul-OSI tests are failing

@Nikul-OSI
Copy link
Author

@Nikul-OSI tests are failing

@dreispt It's not related to our code; it failed because the library didn't load properly.

ImportError: libodbc.so.2: cannot open shared object file: No such file or directory

@Nikul-OSI Nikul-OSI force-pushed the 18_mig_base_external_dbsource_mssql branch 7 times, most recently from 7cd9797 to 4a45348 Compare November 11, 2025 06:42
@Nikul-OSI
Copy link
Author

@max3903 @dreispt Tests and pre-commit now 💚

Comment on lines +28 to +32
def connection_close_mssql_alchemy(self, connection):
return connection.close()

def connection_close_mssql_pyodbc(self, connection):
return connection.close()
Copy link
Member

@max3903 max3903 Nov 12, 2025

Choose a reason for hiding this comment

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

@Nikul-OSI Why duplicating the method if they do the same thing? Each method should handle the different library. Revert to what it was on sunday.

Copy link
Author

Choose a reason for hiding this comment

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

@max3903 connection_close or connection_open function calls a subfunction _get_adapter_method, and this main function concatenates the adapter method with the Connector name.

For example, connection_close + mssql_pyodbc = connection_close_mssql_pyodbc

_get_adapter_method = https://github.com/OCA/server-backend/blob/18.0/base_external_dbsource/models/base_external_dbsource.py#L312

@pedrobaeza
Copy link
Member

Please solve conflicts.

lasley and others added 9 commits November 13, 2025 17:53
… code for reusability * Split all sources into independent modules * Add more test coverage * Add CRUD methods * Add iterator execute return to roadmap

[UPD] Update base_external_dbsource_mssql.pot
[UPD] README.rst

[UPD] Update base_external_dbsource_mssql.pot

[UPD] README.rst
[UPD] Update base_external_dbsource_mssql.pot
[UPD] Update base_external_dbsource_mssql.pot
…heel for pymssql" (OCA#196)

The new `pymssql==2.2.6` version released this weekend
  - <img width="414" alt="Screenshot 2022-11-15 at 20 11 53" src="https://user-images.githubusercontent.com/6644187/202066666-a1551d22-d50a-4c14-ae0a-dd35dc147a40.png">

requires extra setup to be installed

So, it is raising new errors where it is not setup

You can reproduce it running the following command:

    docker run -it --rm  python:3.6 pip3 install -q pymssql==2.2.6

`ERROR: Could not build wheels for pymssql...`

  ERROR: Command errored out with exit status 1:
    command: /usr/local/bin/python /usr/local/lib/python3.6/site-packages/pip/_vendor/pep517/in_process/_in_process.py build_wheel /tmp/tmpmp6b33ly
        cwd: /tmp/pip-install-p4ocn1ip/pymssql_01748f191a744758bda6f7d536f6ec35
    Complete output (25 lines):
    setup.py: platform.system() => Linux
    setup.py: platform.architecture() => ('64bit', 'ELF')
    setup.py: platform.libc_ver() => ('glibc', '2.2.5')
    setup.py: include_dirs => []
    setup.py: library_dirs => []
    running bdist_wheel
    running build
    running build_py
    creating build
    creating build/lib.linux-x86_64-3.6
    creating build/lib.linux-x86_64-3.6/pymssql
    copying src/pymssql/__init__.py -> build/lib.linux-x86_64-3.6/pymssql
    running build_ext
    cythoning src/pymssql/_mssql.pyx to src/pymssql/_mssql.c
    cythoning src/pymssql/_pymssql.pyx to src/pymssql/_pymssql.c
    building 'pymssql._mssql' extension
    creating build/temp.linux-x86_64-3.6
    creating build/temp.linux-x86_64-3.6/src
    creating build/temp.linux-x86_64-3.6/src/pymssql
    gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -fPIC -I/usr/local/include/python3.6m -c src/pymssql/_mssql.c -o build/temp.linux-x86_64-3.6/src/pymssql/_mssql.o -DMSDBLIB
    src/pymssql/_mssql.c:747:10: fatal error: sqlfront.h: No such file or directory
      747 | #include "sqlfront.h"
          |          ^~~~~~~~~~~~
    compilation terminated.
    error: command 'gcc' failed with exit status 1
    ----------------------------------------
    ERROR: Failed building wheel for pymssql
  ERROR: Could not build wheels for pymssql which use PEP 517 and cannot be installed directly
  WARNING: You are using pip version 21.2.4; however, version 21.3.1 is available.
  You should consider upgrading via the '/usr/local/bin/python -m pip install --upgrade pip' command.
  FAIL

However, using

    docker run -it --rm  python:3.6 pip3 install -q pymssql==2.2.5

It is installing well!

So, I have created this PR in order to fix all the error in the CI using this project and installing this package
Updated by "Update PO files to match POT (msgmerge)" hook in Weblate.

Translation: server-backend-16.0/server-backend-16.0-base_external_dbsource_mssql
Translate-URL: https://translation.odoo-community.org/projects/server-backend-16-0/server-backend-16-0-base_external_dbsource_mssql/
@Nikul-OSI Nikul-OSI force-pushed the 18_mig_base_external_dbsource_mssql branch from c1a0c9e to 07245ae Compare November 13, 2025 12:26
@Nikul-OSI Nikul-OSI force-pushed the 18_mig_base_external_dbsource_mssql branch from 07245ae to 5b1b3cd Compare November 13, 2025 12:32
@Nikul-OSI
Copy link
Author

Please solve conflicts.

Done @pedrobaeza

@christian-ramos-tecnativa
Copy link
Contributor

I'm not entirely convinced about the approach taken for the MSSQL ODBC implementation. As it stands, the open, close, and execute methods are identical for both types, and the shared logic is relying on the connector field for filtering.

In my opinion, it would be cleaner to introduce a new field, mssql_type (defaulting to alchemy), in base.external.dbsource, and then use that field for filtering in the _execute_mssql method. This way, the rest of the logic can remain unchanged.
@Nikul-OSI @max3903 WDYT

Copy link
Contributor

@JordiMForgeFlow JordiMForgeFlow left a comment

Choose a reason for hiding this comment

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

functionally tested 👍🏼

@pedrobaeza
Copy link
Member

Superseded by #392

@pedrobaeza pedrobaeza closed this Nov 25, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.