@tim2 just realized there is a select box in the left side - kinda hard to see - which lets me delete

@fred we are already working on an copy project feature :)

@emilrmoeller is this also about the Console? or are you talking about the APIs

what might work for you is to turn the query around. so if you want to filter comments, instead of querying all posts and related comments, you can query comments and filter them and still select the related post

Hey @nilan I’m not sure, i just found this issue and thought it was the same, but not sure. What i want to achieve is to return a list of items thats containing an array of tags. But if i turn it around like this:

allTags(filter: {id_in: “id1”, “id2”}) {
  id
  posts {
    id
  }
}

The response will be

data {
	allTags: [
		{
			id: "id1",
			posts: [
				{ id: "scsjdkhcs"},
				{ id: "djcdsk"}, 
			]
		},
		{
			id: "id2",
			posts: [
				{ id: "cnscds"},
			]
		}
	]
}

But then have no way of making pagination working as i see it 😕 Or maybe i’m missing something?

Yea turning the query around doesn't help in your case. I am not sure on our plans for related filters but we are working on an Algolia integration right now. Would this fit your use case?

also what other information do you store in the tag? it might work to use a list string field on the Post model

@nilan i don’t know what an Algolia is so ill have to look it up. But unfortunately i have to leave now (it’s evening here in Australia), but ill get back to you as soon as i can!

is there any way to export and import a project’s schema and settings? Trying to set up seperate dev and prod enviroments so would be great if we can a) clone a project, and b) backup, export, and import a project

at least the schema and configuration separate from the data

@monkeybonkey We are currently implementing a clone project feature that should allow you to do exactly that. At a later stage we will also introduce IDL based import and export of Project schema.

@nilan sounds cool you are implementing Algolia, i’ts a sweet tool. It’s a bit overkill for what I’m aiming for, but i just remembers in your docs, you’re saying that queries run in sequels, so i could retrieve all id’s and then retrieve all posts of id’s somehow 🙂

Hello!

no, queries run in parallel! it is mutations that run in sequel

hey @phil simple smile

Ah, lol, hmm, but I guess i still could achieve it with 2 queries though, it would just be a bit slower, but unblock me for now 🙂

yea good idea. we have a couple of other things that we are rolling out in the next days/weeks so after that we can get back to related filters.

@nilan that’s just perfectly fine 🙂 From where i see you guys rock! Working on a lot of features, and get them rolled out super fast. It’s just great!

And i still enjoy using it so much

Has anyone heard of someone doing something like create a user with several relations as one mutation? e.g., user has many favourites; favourite has one movie relation; when they issue addUser, they also want to addFavouriteForUser for multiple things

I'm inclined to think it should be at least two requests; one to create the user, one to add the favourites; but someone I'm talking to really wants to do it in one request

that's actually exactly what we do for one-many relations: “Improving DX with nested mutations” @graphcool https://blog.graph.cool/improving-dx-with-nested-mutations-af7711113d6 we call it nested mutations

I don't think that we allow "multi level nesting". What are your arguments for doing it with multiple requests?

So, this would be more like:

mutation {
  createUser(
    name: "em",
    favourites: [
      { movie: "m1", rating: 10 }
      { movie: "m2", rating: 8 }
      { movie: "m5", rating: 8 }
    ]
  ) {
    id
    favourites {
      movie { id, title }
      rating
    }
  }
}

My general argument for doing multiple requests here is that it means everything goes through one set of logic

You don't have duplication of adding favourites logic between creating a user and adding a favourite

You'll probably want to be able to add favourites to a user later

And then you'd just do it as a multi-mutation set;

mutation { m1: addUserFavourite(user, movie: 'm1', rating: 10), m2: addUser... }

you can offer both though

to a certain extent it's a matter of taste how you design the API simple smile