nilan
06/28/2018, 9:47 AMArnab
06/28/2018, 12:28 PMRobby Emmert
07/05/2018, 9:34 AMRobby Emmert
07/05/2018, 9:47 AMRobby Emmert
07/05/2018, 9:47 AMRobby Emmert
07/05/2018, 9:50 AMRobby Emmert
07/05/2018, 9:50 AMRobby Emmert
07/05/2018, 9:51 AMRobby Emmert
07/05/2018, 9:56 AMstanbeguns
07/09/2018, 4:16 PMterion
07/13/2018, 12:07 PMmigrations
table (in fact replicating local migration history). Maybe not very robust solution, but should work. One can locally build a migration process using temps and other tricks to alter/move/add structure and data, than "freeze" the process in migration history and target server will replicate this process
B) Opposite direction: developers use a versioned migration approach as in other frameworks and after migration server generates and outputs final datamodel as a helper for developers to see actual data state in one place
Second variant I see as more solid and controllable, but it fundamentally changes approach to data modeling and requires development of special datamodel-builder syntax and/or special cluster api for this. An example of graphql api for migrations can be something like this:
mutation {
model(
name: "Article",
addField: [{ name: "slug", default: "", index: INDEX_UNIQUE }],
changeFeild: [{ name: "old_name", rename: "new_name", nullable: true }]
removeField: [{name: "old_name"}]
) {
status
}
}
So the migration will be a file with mutations like this. Also this approach simplifies adding basic data: not seeds with test data, but system-critical data, like initial admin account or initial settings, etcfalconmick
07/18/2018, 2:40 AMKlaus Breyer
08/11/2018, 12:14 PMā prisma-zettelv2-backend git:(prisma) ā prisma deploy
Deploying service `zettelv2` to stage `dev` to server `prisma-eu1` !
ERROR: Whoops. Looks like an internal server error. Search your server logs for request ID: eu1:management:cjkpdlfblfo990b30kgyld9ho
{
"data": {
"deploy": null
},
"errors": [
{
"message": "Whoops. Looks like an internal server error. Search your server logs for request ID: eu1:management:cjkpdlfblfo990b30kgyld9ho",
"path": [
"deploy"
],
"locations": [
{
"line": 2,
"column": 9
}
],
"requestId": "eu1:management:cjkpdlfblfo990b30kgyld9ho"
}
],
"status": 200
}
Get in touch if you need help: <https://www.prisma.io/forum/>
To get more detailed output, run $ export DEBUG="*"
ā prisma-zettelv2-backend git:(prisma) ā prisma info
Service Name: zettelv2
dev (cluster: `prisma-eu1`)
So I am clicking through the interface for 30 minutes but can not find any server logs to debug my issue.Dalia
08/16/2018, 7:45 PMveksen
08/21/2018, 4:13 PMveksen
08/21/2018, 4:14 PMveksen
08/21/2018, 4:14 PMdo4gr
do4gr
veksen
08/21/2018, 6:11 PMmakarst
10/04/2018, 4:25 PMtbernard
10/16/2018, 5:21 PMccruz
11/16/2018, 8:49 PMRaeesaa
11/27/2018, 11:33 AMccruz
11/30/2018, 2:17 PMDeploying service `default` to stage `default` to server `local`!
ERROR: There is a relation ambiguity during the migration. Please, first name the old relation on your schema. The ambiguity is on a relation between Member and Message. Please name relations or change the schema in steps.
But the issue only happens in the staging environment. We're using the latest version locally and on the staging site (prisma/1.21.1 (darwin-x64) node-v10.14.1
). We haven't deploy anything to prod. I guess the first time will be ok, but if this issue appears again we don't know how to fixed.senorcodecat
12/13/2018, 12:46 PMnuno
01/09/2019, 12:49 PMgwil
02/12/2019, 11:21 AMprisma deploy
fails due to another problem (like a typo), the type renaming still happens and is not rolled back, which then leads to confusing errors when you try to deploy
again.carstenbaumhoegger
03/15/2019, 9:17 AMgwil
03/18/2019, 12:03 PMTodos
, and I want to add a important: Boolean!
field to them that defaults to false.