SeaQL / sea-orm

🐚 An async & dynamic ORM for Rust
https://www.sea-ql.org/SeaORM/
Apache License 2.0
7.38k stars 517 forks source link

Support Postgres network types (`inet`) #888

Open wbew opened 2 years ago

wbew commented 2 years ago

Motivation

I would like to use Postgres network types (i.e. inet) in my Model definitions. I understand there may be workarounds, so this is not urgent but would be a quality-of-life improvement.

Proposed Solutions

I believe this is nearly/already supported in sea-query: https://github.com/SeaQL/sea-query/issues/187. From my understanding, supporting this in sea-orm requires updating the logic that converts a query result into an instance of a Model: perhaps here.

Additional Information

Currently, attempts to use inet will result in a runtime error.

billy1624 commented 2 years ago

Hey @001wwang, sorry for the delay. Network types are supported on SeaQuery, however, it's only supported by PostgreSQL but not by MySQL and SQLite.

So, the questions was do we want to bring the network types support to SeaORM for PostgreSQL only? Or, support it for MySQL and SQLite as well. We can simply serialize network types as string for MySQL and SQLite.

Thoughts?

CC @tyt2y3

wbew commented 2 years ago

No worries at all, this is not a blocker for us. We only use PostgreSQL so I'll hold off on any judgement for MySQL and SQLite. Thanks for the context.

ikrivosheev commented 2 years ago

@billy1624 I think support network types only for PostgreSQL (for example SqlAlchemy, python ORM, support it only for PostgreSQL).

ikrivosheev commented 2 years ago

@tyt2y3 @billy1624 if it's, I can prepare PR)

tyt2y3 commented 2 years ago

Let me think about it

billy1624 commented 2 years ago

Any updates? @tyt2y3

hut8 commented 1 year ago

I would like this feature! Question about implementation: to what Rust type would inet map? std::net::IpAddr seems like a logical choice, but Postgres's inet type also can contain the subnet. So I guess we would have to just discard that, right? Is there a better type?

Razican commented 1 year ago

One option would be ipnetwork, which is already supported by SQLx (and diesel), but it's not stable, and SQLx itself is not able keep the version up to date: https://github.com/launchbadge/sqlx/pull/2148

Another option is ipnet, which has a stable API, many downloads and updates, and it's supported by diesel too, for example.

holmofy commented 1 year ago

What is the current progress on this issue? I found that sqlx already provides inet type support for postgresql :https://github.com/launchbadge/sqlx/blob/main/sqlx-postgres/src/types/ipnetwork.rs

tyt2y3 commented 1 year ago

The issue is still outstanding. No concrete plan for it yet.

oovm commented 1 month ago

with-ipnetwork doesn't seem to exist in cargo.toml?

https://github.com/SeaQL/sea-orm/blob/039e4423d3ef2fe4959c0b19c2b37bbd3f90d9b9/src/driver/sqlx_postgres.rs#L559-L573

lpotthast commented 1 month ago

With roughly this set of dependencies and features

sea-orm = { version = "1.1.0-rc.1", features = [
    "debug-print",
    "runtime-tokio-rustls",
    "sqlx",
    "sqlx-postgres",
] }
sea-query = { version = "0.32.0-rc.1", features = ["with-ipnetwork"] }
sea-query-binder = { version = "0.7.0-rc.2", features = ["with-ipnetwork"] }

where, sea-query and sea-query-binder are only needed because sea-orm has no "with-ipnetwork" feature that would get passed onwards, I am able to define a wrapper new-type

#[derive(Debug, Eq, Clone, PartialEq)]
pub struct IpNetworkWrapper(pub ipnetwork::IpNetwork);

and use it with DeriveEntityModel. Inserting works fine, but parsing a DB response I cannot get to work. How should a TryGetable implementation look like?

tyt2y3 commented 1 month ago

Of course it'd be nicer if we can integrate this all into SeaORM. For ref: https://www.sea-ql.org/SeaORM/docs/generate-entity/newtype/ https://github.com/SeaQL/sea-orm/blob/master/sea-orm-macros/src/derives/value_type.rs

Leo1003 commented 1 month ago

I found it is hard to implement TryGetable without having access to the underlying row data in QueryResult.

Although sqlx::Decode is implemented for ipnetwork::IpNetwork, we cannot get an appropriate type from QueryResult to use it. I think it is hard to support new SQL type outside of sea_orm.

Therefore, I tried to implement it in sea_orm directly and submit a draft PR.