Dependencies: Version incompatibility - What is the way to go?

Update: looks easier than expected again (one has to love elixir libraries): there is a few :unicode.characters_to_binary(:unicode, :latin1)
in the type casting of mssqlex. using utf8 instead seems promising. Not tested for inserts or timestamps yet… but I am positive that this all can be achieved

Correction: at the moment the result parsing works seemingly again. I don’t understand what version of which part of my setup (umbrella) caused the problem earlier… I guess I was running on earlier compiled stuff still or similarly. In oder to get correct strings I have to “normalize” them like this:

I have to call SELECT NORMALIZE('Å', 'NFC') FROM ... for the string variables in order to get the proper encoding… but this is not a problem for my read only queries…, just maybe something to optimize.

I guess this is something Hana specific, or would you know such a pattern, is that an “encoding” thing which I also could solve via the Driver?

I’ll have to do some testing, and then maybe just to approach the MssqlexV3 People. Just, you seem to have some SQL experience. Best, Tschnibo

Edit: I see that I have to read on here: https://hexdocs.pm/elixir/master/unicode-syntax.html#r6-filtered-normalized-identifiers

@kip , you are totally right. But one persons hard work would be maybe a simple task for others. I guess that extent of patching I did would require other people 5 min max.

I just installed a configurable “ping” statement and a “configurable” Connection key (to map “Server” → “servernode” I think).

What I want to say, the whole thing basicly just connects. And what is missing (what was working for the older mssqlex beliefe) is the parsing of the results into maps. Also I have not tried writing or something similar. But I probably (not 100% sure) look into this things too, at least the parsing. And if this would be slightly more involved and I would succeeded, then this might get to a level where a PR or public Fork or whatever would become interesting. Of course if somebody else would require a Hana connection, this could be a motivation - or this person could maybe help me with my limited skills.

Anyway, thank you, you are motivating me to dig a bit deeper!

If as a result of your hard work you have a patch that makes it possible to use MSSQLex with SAP HANA then I’m sure the maintainers would be interested in a PR.

Its definitely not a mainstream open source DB but as someone who spent 10 years at SAP I know its a platform that enterprises spend a lot of $$$$ on so perhaps an opportunity for enterprising Elixir developers.

Small update
It was a mistake in my patch which prevented me from using MssqlexV3 for Hana too.
Now that is fixed I do get my connections as desired. So back to one mssqlexV3 version (patched) and correspondingly to one DBConnection dependency.

Do the “do you really need two different versions” people always win at the end?

Still glad for learning a lot by renaming modules and stuff Good to know that such a dependency issue is not a dead end.

Thank you for thinking through and for this idea!

Actually I might even sometimes have thought about something in this direction. But at the moment this would be “over my head” and maybe as you said complicated in another way. Especially for developing, I would need to run one app separately adding sort of an “API-Layer”. If I understand this correctly. Then again I would learn about nodes…

I also had a look at umbrella projects, but they are explicitly no suited for that problem.

So the forks are maybe really “the way to go”. What I was thinking: could one write an slightly adapted compiler / compiler plugin which takes a mix.exs or config file entry and prepends / renames specific module names accordingly? I mean I just did the whole forking stuff, no real need right now. I am more just thinking if there could be a simple solution. The larger the ecosystem gets, the more such “dependency problems” can occur I assume. What strikes me is on one hand, that the problem can be solved by renaming a package and on the other hand that it is solved that way. But of course I see that every added complexity to core functions as compilation do make the whole thing more complicated…

Right. So there’s one more option but I am not sure if it’s any more less terrible than what you figured out. Maybe, maybe not. You could set up non-homogenous Erlang/Elixir cluster where one node has an app loaded on it that talks to sap-hana, and other node has deployed app that talks to microsoft-sql…

Again, I am not saying it’s a good solution as it’s got it’s own set of problems in set up like that, starting with way more complicated deployment scenario, but it would be an alternative to what you do.

fair I use mssqlex in the “original” version which comes with db_connection v1.1 for sap-hana
(just because it works with only minor changes) and then the mssqlex_v3 package which depends on db_connection v2.0 for Microsoft-SQL.. I only read on the DB’s. Internally I use mongdb at the moment.

out of curiosity: which package you had the need to have included twice in the project?