Hey. We have an issue with joined fields. For sche...
# community-help
d
Hey. We have an issue with joined fields. For schema management we decided to use aliases. Our collections are called
<type>-<schema-hash>
(ex: "projects-eef62f97"). We create a "projects" alias that all clients use so any migrations are transparent to them. When we want to do a schema change: we create a new collection (new hash in name), fill it with all data, switch the alias to it, and delete the old one. This works perfectly for normal searches. But now we want to use joins. Our current idea was that we also reference the collection name in the respective schema to keep the references clean:
Copy code
projects-<ver1>: [{ type: "string", name: "id" }, ...]
documents-<ver1>: [{ type: "string", name: "projectId", reference: "projects-<ver1>" }]
But now, when we want to include the data from the other collection we need to do
include_fields=$projects-<ver1>(*)
meaning the client needs to be aware of the name of the hash-collection name. But we do want to avoid that with the before mentioned alias setup. What are our options?
a
Hey @Dominik Henneke , Yeah, your idea is the best for avoiding using aliases. You just have to make sure you have <hash> at hand at all times, but the GET /collections return created_at field that you can use to different older and newer collections.
d
Is it possible to rename the field where the join is happening, except from the โ€žmergeโ€œ strategy? We are also using presets so we could also try to hide this mapping there. But then the client still would need to know how the field is called. Though we could also build something that only cares about the field with the prefix
h
@Dominik Henneke You can provide alias
include_fields=$projects-<ver1>(*)
here instead of hash name and it would work fine.
When we want to do a schema change: we create a new collection (new hash in name), fill it with all data, switch the alias to it, and delete the old one.
The only caveat is that now you'll have to also re-index the collection that has the
reference
field when you re-index the referenced collection. https://typesense.org/docs/29.0/api/joins.html#using-aliases-with-joins
d
I don't think that will really work for us. We currently migrate all collections that depend on each other at the same time, and only then switch all these aliases to all these collections at the same time to ensure the references are all working and the update is "instant".
h
If you're already migrating all the dependent collections together then there's no need to worry about mentioning collection's alias name in
include_fields
. When you switch the aliases, you won't have to make any changes to the
include_fields
since it'll also be affected by the alias change.
d
But if the new collection references the alias, then it would point to the "old" projects collection and not the new one that was just created but is not live yet in the alias.
h
You should provide the hash name in the
reference
parameter of the field but you can provide the alias name when querying.
d
hmm interesting. I tried that but it didn't work. I will try again
h
It should work. If it doesn't, please share a minimal example, I'll be happy to look into it.
d
You are right. That works! Thank you ๐Ÿ™‚.
๐Ÿ™Œ๐Ÿผ 1
We also do sharding (there are 16 collections of everything) which makes it a bit more complex, but we can simply provide also 16 different presets that each reference the respective alias. But that's easy
h
Yes, that would work.