Hi everyone! Am I right that currently, in order t...
# ory-network
g
Hi everyone! Am I right that currently, in order to update an identity, I have to use the REST API because neither Ory CLI, nor the Ory Network UI allow to do so?
h
Hey Daniel, unfortunately that’s the only way to do it right now. What would be your preferred way?
g
I’m currently trying to figure out what’s the easiest way to migrate users to new identity schemas. And from what I can tell Ort currently does not offer any support that apart from using the API, right?
h
That’s true. We’re still looking for good ideas how to make migration easier. Especially with more users, this is going to get more and more difficult. We had some ideas with Jsonnet but nothing concrete yet. Could you briefly tell us what transformations you need to do?
g
ATM I’m mostly trying to understand the process in order to plan ahead. But I’ve also noticed that our users have different schema IDs. We had two modifications of our schema but we only added optional fields so the system works with all users as they are. If I want consistency, I need to migrate users. That triggered the basic question: how to migrate? At this point of time, it would even help to have
ory update identity
or
ory patch identity
available so I could shell script a little. Doing this via REST calls is obviously also possible though but the CLI feels a little inconsistent here in the sense that
update
and
patch
are available for other resources but not for
identity
.
Thinking out loud crazy ideas… maybe it would be nice to have something like a cloud function (maybe a pure function running inside a WASM container) provided by Ory users that represent a migration from id_schema_v_x -> id_schema_v_x+1
Then you could chain migrations like you do with any DB migration tool and offer some convenience functionality in ORY cli to trigger the migration (of a subset) of users.
Never worked with Jsonnet though, sounds easier from first sight but also more limiting.
h
I think we’ll need to have something that you can execute server-side, to speed up the process
Ok, but generally speaking adding the identities command to the CLI shouldn’t be much work ..
g
Yes, but it wouldn’t be such a big difference to using the REST API with patch and
curl
or HTTPie or similar…
Also, when shell scripting you also have to do the paging (which is doable but annoying).
Also, the REST API is somewhat limited wrt. query options (
credentials_identifier
being the only query param) if your use case is to select a subset for migration (not my use case though).
Hmm… maybe it would be… assuming I have a migration v1->v2 and one for v2-> v3 I need to migrate identities with v1 first, then with v2. Currently, I don’t see a way to query it. So I would be left with querying all identities, then selecting a subset on client side.
Obviously all of this wouldn’t exactly be transactional. So if the system is under heavy use I could totally mess up some things if not done right. So, yes, a well-designed server-side process (ideally transactional) would help 🙂
h
Thank you for the feedback, really helpful! What’s the thing we can do to help you as fast as possible? A CLI command for this?
g
CLI command would be more convenient but no strictly required. Can use the REST API as fallback.
Awesome would be more filters for listing users, but that’s also more effort on your side.
h
we have a search api on the backlog but yes this is not trivial, especially because it contains PII ..