Repository navigation
Conversation
roji
changed the title
Co-authored-by: Shay Rojansky <[email protected]>
|
Hi @roji, thanks for the PR! Merged the FactoryResolver change in the commit above. I think support for |
|
@ankane that would require setting up a build with .NET Framework, on a Windows machine (or Linux with mono - let me know if you have a preference). The sort of stuff being done in the plugin is generally very portable and differences between .NET Framework and Core are very unlikely to affect it; but if you think that CI test coverage is important here (as opposed to a one-time test which I can certainly do), let me know and I'll do it. |
|
Looks like it'll fail to compile if any of the guards are missing, so think that should be fine. Need to get some sleep, but will look at this tomorrow. |
|
Sounds good, thanks! Will rebase on top of latest master. |
Plus: * Bump dependency patch versions * Minor simplification
7962d0a to
8f85c6f
Compare
|
I just noticed Npgsql no longer supports I'm not sure if there's much benefit to adding this and releasing it as 0.3.1 since:
Thoughts? |
|
@ankane I'd advise to not necessarily eagerly bump the Npgsql dependency unless there's a good reason to - the extensions should work fine on both Npgsql 8.0 and 9.0 (am happy to submit a PR that adds CI testing for that), and as pgvector evolves, it's better not to lose users for no good reason. With Npgsql 8.0 specifically it's even stronger, precisely because it's the last version to support .NET Framework/.NET Standard. We know that there are quite a lot of framework users out there, which ideally would be able to use the latest pgvector versions - unless that places an unreasonable burden on this library. Let me know what you think. So yeah, this is currently about allowing |
|
Thanks, will support it for now (although I don't think the situation is too different from npgsql/npgsql#5296). It'd be nice to test both Npgsql 8 and 9 on CI (as well as .NET 9) if it doesn't add too much complexity. |
You're right in a way - it's mostly that Npgsql is a much bigger beast and keeping netstandard2.0 was much more of a maintenance and performance drag, whereas here it seems to be mostly free (except for those few #if directives). In any case thanks - I'll put together a PR for adding tesing. |
|
Sounds good. Will release 0.3.1 for both packages tonight. Also, I tried tackling #44 a bit ago but didn't have any luck if you have the spare cycles. |
|
Will take a look - in principle, if the types are probably registered with EF's TypeMappingSource, everything should just work. |
Hey @ankane 👋
I'm currently working intensively on a .NET abstraction for vector databases - Microsoft.Extensions.VectorData; see this announcement (though we've made considerable progress since). PgVector is obviously an important implementation and we're working to make it work nicely there.
One thing we've centralized on is netstandard2.0 and net462 support across the board - wherever possible - to make sure absolutely everyone can do vector search: there are quite a few applications out there still stuck on .NET Framework, and I'm trying to make sure nobody gets left out. I noticed that pgvector 0.3.0 dropped netstandard2.0 support, presumably because of the added support for the .NET Half type, which was only introduced in .NET 5.0.
So here's a PR adding back netstandard2.0, using simple conditional compilation to not have Half there; it's all pretty straightforward and allows .NET Framework users to use float embeddings. Note that it also adds a net462 target explicitly - that's recommended since netstandard2.0 has issues under .NET Framework 4.7.2 (docs, under "CONSIDER adding a target for net462 when you're offering a netstandard2.0 target"). None of that complicates the code in any significant way.
Additional things I threw in: