Add a `seed` command to create and update data in custom collections

[EdouardDem]

Reported here: https://github.com/tractr/directus-sync/issues/1

Work in progress in this branch: https://github.com/tractr/directus-sync/tree/seed

[craftyshaun]

Howdy @EdouardDem, I've got a use case for this feature and was wondering if this is progressing.

I understand that the Open Source code is the best effort, and I appreciate the work that has been done with the extension thus far.

I mainly want to make sure anything I 'hack up' myself isn't wasted, as you've got some updates to the seed branch hiding somewhere. ;-)

[EdouardDem]

Hello @craftyshaun. I've been very busy these days and other priorities have come up. However, I've been thinking about this feature. I see two ways to implement it, one difficult and one easy.

The difficult way

In this case, the seed command works as a 2-way synchronization. This includes:

• the ability to extract custom data from Directus
• the ability to diff custom data with another Directus
• the ability to push custom data to another Directus. The difficulty here is that we need to introspect the schema in order to know the relationships between the data models. In addition, during seed, we need to push the data in the right order to avoid dependency breaks.

The simple method

This approach is similar to the [seed in Prisma] (https://www.prisma.io/docs/orm/prisma-migrate/workflows/seeding). Here, you manually define the data to be seeded in a JS file. You're responsible for defining the relationship between models and also the order in which entries are created.

Initially, I'll go for the easy way. I can implement this solution in the next 10 days. Later, we can implement the other solution, if enough people request this behavior.

What exactly do you need?

[craftyshaun]

Hello, @EdouardDem understand about priorities...

What exactly do you need?

My use case is some developers have created some 'static' data in a staging database that we now need to get to prod. This 'static' data is lookup data. An example is a list of banned words for a community forum. They wish to execute point in type syncs from dev -> production for an initial starting point.

Initially, I'll go for the easy way. I can implement this solution in the next 10 days. Later, we can implement the other solution, if enough people request this behavior.

I'm all for KISS, so I'd say it could work, with a tiny caveat. We try to implement some way to 'dump' a collection from directus into an importable format.

Understanding that if the collection has a 'relation' to another table, it's up to the 'user' to import these in the right order. So, we ignore numbers 2 and 3 above with an at your own peril' type caveat.

Stepping back from this and treating directus as 'the data layer,' the Prisma definition sounds a lot like a traditional database seed (or migration), which, IMHO, belongs alongside the application code (not the database tooling).

If it's easier for my use case (which may not be normal), I can write the migrations in the application code. Then, I can write some import/export tooling to update these static migrations.

Later, we can implement the other solution, if enough people request this behavior.

The 'coolness' of this project is the diff/sync. I'd love to see this done with the data as well. Hence, I'm happy to do it manually so you can save energy for this 'complete' diff/sync.

EDIT: Added my views on full sync