Skip to content

Conversation

@jayvdb
Copy link
Collaborator

@jayvdb jayvdb commented Oct 31, 2025

Closes #392

I am not advocating arrayvec::ArrayString - it looks wrong, because dbs store chars, but this crate is about bytes.

@jayvdb jayvdb force-pushed the fixed-size-string branch from e268ca6 to 72bdd8b Compare October 31, 2025 02:50
@jayvdb jayvdb changed the title Add support for arrayvec::ArrayString Add support for fixed length strings Oct 31, 2025
Copy link
Owner

@Electron100 Electron100 left a comment

Choose a reason for hiding this comment

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

I don't think I've quite understood what you were trying to achieve here. From #392 I initially thought you were going for something that would be represented as a fixed-length string through to the SQL backend (e.g. CHAR(n) in Postgres). This is just supporting ArrayStr as a usable type in models that ultimately goes through to TEXT. Which is OK, but I want to make sure I've understood your intention correctly?

turso = ["async", "dep:turso"]

[dependencies]
arrayvec = "0.7"
Copy link
Owner

Choose a reason for hiding this comment

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

I'd prefer for arrayvec (or whichever we land on here) to be an optional dependency

@jayvdb
Copy link
Collaborator Author

jayvdb commented Nov 1, 2025

The goal is to be using VARCHAR(x) in the schema def. So far, this is just getting the Rust side of things. Next step is Switching from arraayvec to a type that can match VARCHAR(x) of utf8. Then fix the migrations to use VARCHAR(x).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Fixed length strings

2 participants