"Composite Type" question

When you have a field in Type “X” as a “composite type” - bubble’s way of associating an entry to another entry from a different Type, for example Type “Y” -, and you let the user create a new entry in Type “X” which includes filling this composite field’s value, (and hitting save button with workflow to create a thing in Type “X”) would this create a new entry in Type “Y” as well?

If the answer is yes, then when the user comes back to Edit the value in that composite field - for example correcting a typo - the last relationship will probably be lost and bubble will create a new thing in Type “Y” with the new value.

If im correct then here is the problem, since i have other fields in Type “Y”, i would want this specific entry of Type “X” to be associated to this specific entry of Type “Y” even if the user makes an edit.

Or maybe the way it works is that once you created an association to an entry of another Type, bubble connects it by the ID, regardless of the Composite fields value changes, which is also a problem: what if the user do wants to change the association to a different entry of Type “Y”?

No.

If the Y row already exists, then you can create X with a reference to the existing Y. (so select something on a Dropdown set to Type Y.

If the Y row doesn’t Exist, then you need to Save the Y first, then Save the X with reference to Y. And then if you are being multidirectional with your relationships, update the Y with the X.

When u say “multi-directional” you mean: if i want Y to be related to X as well? isn’t this automatically?

And what do u mean “update the Y with X”, how would i do it?

The way i understood it is, that once an entry in X has a relation to an entry in Y, the same is true that Y has a relation to X regardless where the composite field lies, in X or Y.

Or does it make a difference? for example when it comes to build searches and other expressions?

Nigel means a direct relationship, rather than an indirect one you have to search for.

For example, Y has a field “my x” of type X, so you can write Y's my x instead of search for X constraint ref has Y.

1 Like

So your’e saying that when i want Y to be related to X and later write some expressions to find related things, i should always create a “Composite field” on both sides, Y and X?

Or what does multi-directional mean, is there a situation where you wouldn’t want it to be on both sides?

Thanks for clarifying

For example, a shopping cart’s items might not need to refer to their cart, if they will always be retrieved in the context of a cart.

I won’t pick parent-child as an example, because there’s always the question “who’s ya daddy?”

Yeah, I meant an explicit relationship, rather than an implicit one.

It is easy enough to spot you need one, when you have to do a search rather than use “apostrophe language”. So …

Vehicle’s Manufacturer’s Name rather than Search for Manufacturers … Constraint Vehicle List Contains This Vehicle.

I tend to build them explicitly both ways, as it doesn’t take much extra effort. But if you don’t think you need it, then don’t.

How would you do it? is it by having the field in Y (that X is referring to) as a composite field referring back to X as well?

For Example in type X, field “Name X” is referring to “Name Y” from type Y, so to build explicit relationship, should i have “Name Y” refer back to “Name X”?

Or should i get a marriage counselor immediately to talk relationships… :joy:

No, this is far simpler :slight_smile: It is as you described.

In a current app, I have bloggers who are writing blogposts.

So on my “parent” - Blogger, I have a list of Blog Posts “BlogPosts”

And on my “child” BlogPost I have the Blogger who wrote it “Author”.

So a one-to-many relationship that is navigable in both directions without having to do a search.

@NigelG

i know its from a long time ago,

here is my question:

When you’re saving a piece of data that you want to be bidirectional for direct referencing, how do you “remove” the relationship on both sides when one side gets deleted or updated?

in your example:
Say you want to change who the author of blog A is, you would create an action that “changes parent blog” and select the new user (author), now you would “change parent blog’s user” and “add” parent blog to its “blogs”.

But how would you tell bubble to remove parent blog from the previously linked user? how do you point bubble to the old author when its already un-linked from the parent blog ?

(I understand that you could do the “remove” action before the “add” action so you still have a reference to the old author via the blog side, but that would still not work for a many-to-many reationship, so lets say a blog can have multiple authors, and now you change who the authors are from a multidropdown, some old stay, some old is removed, how do you tell bubble which to “remove”?)

@NigelG

(by the word “parent” i didnt mean to use it as you used it in releation to parent-child, i meant parent thing, in case you getting confused)

OK, so if you have Author >one-to-many> Blogposts …

You know, Old Author, New Author, Blogpost

Update Blogpost’s Author with the New Author
Update Old Author’s list of Posts to remove Blogpost
Update New Author’s list of Posts to add Blogpost

If you have Author >many-to-many> Blogposts …

You can’t model the many to many, so you create two one to many’s and a link table.

Create a new table called “Blog Author” which has two fields, Author and Blogpost

Then both Author and Blogpost tables have a field of List of Blog Authors.

You know, Old Author, New Author, Blogpost

Delete the Blog Author for Old Author & Blog Post. This removes it from the list on both other tables.

Create a new Blog Author with the New Author. And add this to the lists on Author and Blogpost.

Quicker to do in Bubble than to describe !

Does that make sense ? Or do you need an example ?

1 Like

Thanks @NigelG i see what youre saying

Meanwhile i came up with a way to do it without requiring a new table, tell me if im right

Always remove parent thing from currently associated thing/'s, before reseting the new list/thing associated to the parent and adding parent to new assiciated list/thing.

So always:

  1. remove parent thing from currently associated thing/'s.

  2. reset the new list/thing associated to the parent thing.

  3. add parent thing to new assiciated list/thing.

That way u always have the correct list on both sides regardless whether you’re creating, modifying, or deleting, and regardless which side you’re currently editing, the many or the one.

Yes, that works too.

But as soon as you want to have a list in order of, say, authors added date… you can’t, or want add in some information about the relationship between the two tables …

Then you need a new table.