Closed leontoeides closed 1 day ago
I wonder, is #[secondary_key] necessary if #[native_db(secondary_key(custom_name, optional))] is defined?
Actually, no, it's not linked. You can have as many secondary_key
associated with fields as you have custom secondary_key
defined in the macro.
Here are some examples:
Each time it is a new key whether it is custom or not, you can have a mix of the two without any problem. And you can create as many as you want.
Does this answer your questions?
Thank you, yes that did answer my question.
I still think it would be very useful to be able to return an arbitrary number of secondary keys for a record using a function or by implementing a trait for the struct?
Just a hypothetical example here - let's say each struct in the database represented a country. A person could use an enum
as a key:
enum CountryKey {
City(String)
State(String)
}
struct CountryValue {
cities: Vec<String>,
states: Vec<String>,
}
let united_states = CountryValue {
cities: vec!["Houston", "San Antonio", "Galveston"], // etc.
states: vec!["Texas"], // etc.
}
The custom #[native_db(secondary_keys(function_name))]
function could return a collection of cities and states for the CountryValue
. For example:
[City("Houston"), City("San Antonio"), City("Galveston"), State("Texas")]
And then when searching the database for City("Houston")
or State("Texas")
the database would return united_states
struct.
It's an interesting idea, I see several things in your example:
City
is used as a key.
According to the documentation regarding secondary keys a custom function can be defined in the macro that can be used to finagle a secondary key from the user's struct.
The following tells
native_db
to use the user-supplied functioncustom_name
to get the secondary key for the struct:I wonder, is
#[secondary_key]
necessary if#[native_db(secondary_key(custom_name, optional))]
is defined?The user-defined
custom_name
function returns anOption<String>
as the secondary key:Since, according to the documentation, users can define "define it or not, define one or more" I assume it should be possible to return multiple secondary keys for a single struct?
If so, I'd like to propose an additional
secondary_keys
definition that can return aVec<T>
rather than anOption<T>
. If the secondary key isn'toptional
, an emptyVec
would fail.I get the impression that
native_db
's internal structure should support this, it's just a matter of implementing the feature? Any thoughts?