Datasource best practices

Guillaume Maison

Hi all,

i have a question about the best practice regarding managing datasources.
By default, the datasource is live. If you create a datasource, by default it's named test.
BUT, if i'm not mistaken, you can do schema modifications only in the live datasource while any modification impacts all the other datasources, only the data are completely separated and isolated.

So, in fact, to be sure that i "never" make a mistake, wouldn't it be best if the live version is considered to be the dev/test one and create another datasource to set it to the production through some specific process (and very hard to change once set) ?

Or even, as by default, from the first plan, you can create more than one datasource, why not create a test and a live datasource. By default you work on the test datasource and the app sets its X-Data-Source to live while in production ?

Any feedback about best practices with datasource much appreciated :)

Thanks

Best regards,

Chris Coleman

Hi, @Guillaume Maison. Definitely an interesting question that I think prompts some discussion. Would love to hear from other community members here.

I haven't launched an app myself, so I may be missing some logistical issues, but it seems to be the ideal scenario would be that if you want to push updates to your schema, you do so by creating new columns, migrating (via copy) the existing data, and update references to use the new column in your APIs. That way, your existing schema continues to function and the new column is used in production as soon as you push your updates live.

Guillaume Maison

@Chris Coleman Thanks for your answer.

I'm not specifically speaking about transferring data from a datasource to another datasource.

I'm rather talking about schema management :

Actually, for example, i have a live datasource and i add a new one with name test.

By default AND if i don't mention x-data-source in the header, i do work on live. if i need to do some schema modifications, i need to go to live datasource then to go back to test datasource to manipulate data and so back and forth each time.

imho, by default, i should be in "i can have inconsistent database" (eg test) datasource (especially if i don't mention it in the x-data-source header) where if i do modifications (except for modifying schema) it doesn't impact the live environment. Plus, the fact that it's in test/dev datasource that i am the most subject to do schema modifications (even if such db schema modification impacts all the datasource —> you just have to know that renaming or deleting a column impacts al lthe datasources, so you don't do them specifically until you've pushed live your app that doesn't use anymore those renamed or deleted fields)

Guillaume Maison

@Ray Deck any feedback on this ?