Polymorphic relations. When creating relation, ability to have many Types from which to choose, and not just one Type

Wanted to bump this, and @Oshyan brought it up in another thread before I had a chance to!

I’m going to leave my hastily written use case for Polymorphic in the other thread, but here’s a link to it for reference:

https://community.fibery.io/t/seeing-closed-entities-grayed-out-in-search-dialog/1298/10?u=b_sp

Ah yes, Polymorphic…funny I was thinking the last week how to add in some additional use case stuff to try to move that along. You’ll recall @mdubakov mentioned here that the work involved isn’t too complex:

In an effort to paraphrase what I wanted to explain as a much more detailed post, I am seeing an increased need for Polymorphic around creating hierarchical “grouping” style Apps. A situation where I would use an app and a series of child Types to group other Types, much like you’d use Folders in an old-school file system. The key is that in some cases you need just one level of hierarchy, in others say 4 or 5. Without Polymorphic, you have to always have the bottom level used , otherwise you would need to create extra relations to have something grouped on a higher level than the bottom.

So say you have something like this:

Function → Subfunction → Specialization → Area

This would be used in categorizing some work in a business, such as:

Marketing → SEO…in this case, you would not need to go down further to level 3 and 4, but you might have:

Marketing → Paid Campaigns → SEM → Google Ads…in this case the four levels are essential, as you could have another one here after “SEM” of “Facebook Ads” right?

With Polymorphic, I can choose at which level I relate to the entire App described here. That is just like if I’m creating a file folder in, say, Google Docs, for my Company functions. I can create folders on more than one level, and that works nicely.

Let’s hope Polymorphic continues to gain support - I’m glad to see it’s so popular now with Votes, although not sure if that’s giving it enough weight on the overall points scheme within the entire feedback system on the Fibery Roadmap!

2 Likes

Thank you for the comment, it indeed describes the value well. Some comments from me:

  1. With blocks we gave this feature more priority, since there are things that can’t be done without polymorphic relations
  2. I seriously underestimated effort, it is much harder to do and it’s a significant technical challenge.
  3. I hope we’ll do a spike in the next months to see how hard it is to implement.
3 Likes

I wanted to just let you know that I moved my vote here over to the request here:

Right now I need that above request more than Polymorphic, but it’s hard for me to quantify to what degree having said that…

I would really like to also point out that I don’t understand the 5 vote limitation. In particular for many of us veterans of the forum, it would be nice to be able to vote on more posts. I think Team Fibery could give us some good faith that we won’t go voting willy nilly. I think it’s odd and artificial that I have to remove a vote here because I don’t have enough.

I’d also like to pose the question to @mdubakov around this point, and @Oshyan eager to get your 2 cents too, that do you guys limit feedback in your back channel to just 5 votes per user? So if a user writes in a request a 6th time, how would you figure out where to remove the vote? I’m asking because you’ve generously shared your backlog and votes around features in the past, often showing that requests you get directly from users have far more “weight” in votes - and that’s how you showed them, with actual numerical value - than requests here in the forum. I recall that Polymorphic barely showed up in the chart here:

yet it’s the top category now that we have votes.

Hope that’s useful. Would really like more votes, because without them I think we have a skewed view of requests. And would really like to know if you impose this limit on the “internal” tracking of users. Thanks!

1 Like

I don’t see anything about Polymorphism in the chart at all.

A post was merged into an existing topic: Feedback management problems + now you can vote for missing use cases here :mega:

I accidentally posted a reply here, when I meant to move it to a new thread. And although there is mention of it above, I wanted to just make a new reply here to make sure @B_Sp saw it was a reply to this topic. Will be more careful about which thread I am replying to in the future. :joy:

It is there at least on the “List” view:
https://vizydrop-svc.fibery.io/svc/vizydrop/shared/drop/5f92fb44c717c161b4e48265?authkey=34f99b058d01e0b41a96

2 Likes

Would love to get an update here guys.

My team has come up on this again as we build out new areas with multiple levels. We are building some multi-level structures in a software system. Basically, three apps, One has 4 levels, the other 3. There structures are in turn connected to a couple of types of Dev work items in other apps: We have multiple story types (Technical, User) and related tasks and bugs.

As we build it out, we are seeing that in some cases, structures don’t all have four levels. There are items on level three, or two even, that are the end of that particular “tree.” The stories need to link to the item that is being built, though. So without Polymorphic, in order to have the relation of a story to all levels I need, I have to have three Types in the hierarchy relate to the Story Type in the other App. This is getting very unwieldy. Or, I have to artificially create items in my structures down to the bottom level of each app, even though in reality this may not reflect how my structure looks.

This is basically a repeated instance of multiple examples I already posted in this thread, but just wanted to add yet another use case here.

Glad to see we’re up to 10 votes here, really hoping for some movement on this soon!

2 Likes

I don’t mean to be the primary torch holder of those of us really eager for this feature, but since it is about 1/2 year since @mdubakov weighed in here, would love to get another update on the team’s thoughts around this. I’m aware we have a good deal of visibility into what you are working on right now, such as blocks and new Entity View - both of which I eagerly anticipate. But my team still has a bunch of big things we want to do in Fibery, mainly around hierarchies we need to represent, that are blocked by the lack of Polymorhpic.

Would even be happy to hear if you guys think this might be addressed in the next 1/2 year, or not till 2023, etc.

In closing I’ll just add that if you can get this live, it will be one of Fibery’s truly differentiating features in the market and I think you guys should leverage it when completed to pick up some of the networked-thought folks flocking to Roam/Notion etc. as those tools have nothing like this. And I’m sure they don’t even have it thought through and on the dev radar yet, you guys have a leg up here!

Thanks!

2 Likes

I notice in the schema lots of fields related to “Mixins”. I assume that’s not something that could be leveraged for this purpose, or it would already have been done.

'fraid not, sorry.

I have a concrete issue that relates to polymorphic relations:

First, i have a bunch of cases for which we need to allocate time periods and people. But the cases belong to different entities, e.g. Contracts we are delivering on, marketing Campaigns, and business Opportunities we need to develop. We feel the need to have the planning aspects in one place.

So, i have created a Case DB with one-to-one relations to each of those three. The Case entity contains fields that all three need, and the three separate entities contain the fields that are unique to each. So, a Case should only by linked to one Contract OR one Campaign OR one Opportunity. Essentially, Contracts, Campaigns, and Opps subclass the Case class with their unique fields.

The other option would be to give Cases the union of all fields of those three entities, and replace the separate entities with a category label. But that leaves a lot of unused fields, and invites the risk of using the wrong fields for a given category.

My “inheritance” or data deduplication system works, but there is no protection against multi-classing a Case by mistake (linking a Case to both an Opportunity and a Campaign, for instance) which messes our planning up because we double-book resources.

I would like to collect Contracts, Campaigns, and Opportunities under a group label and give Cases a one-to-one relation to that group. I believe this use case falls under the umbrella of Polymorphic relations.

\m/

1 Like

Sounds a bit like what’s discussed here

1 Like

Just wanted to check in and see if there is any specific update on when this important feature might come out? The need continues to grow for my team as our Fibery instance grows and we add in some new uses, such as some customer management, tracking of vendors, and other business stuff that Fibery is well-suited to manage.

Thanks!

4 Likes

Personally I’m hoping that when we get some form of “field hiding” (soon??), that it will be dynamic, i.e. have the ability to hide different fields depending on the current value of some single-select field. Just like a Formula or Rule. And ideally, also based on what View is currently being displayed.

6 Likes

This is a great point @Matt_Blais and right in line with Dependent Dropdown Field Type that I hope also comes along soon!

@mdubakov Hey! I think this concept of polymorphic relations is really interesting. I’ve been working a lot with graph databases like ArangoDB, where you get polymorphic relations built in. There are some things it’s not quite as good at compared to relational databases (where you can rely upon a schema), but with modern stacks, it’s still fast enough without schemas to work just fine for me.

That’s sort of a ramble. My main point is that I’m really interested, conceptually, in how Fibery works, and I’m wondering if you’d ever be willing to share, publicly or confidentially, the architure of the platform. I’m not interested in stealing intellectual property or using it to build a competitor or anything; I’ve just enjoyed learning more about how products like yours - that are sort of on the forefront of what humanity has ever seen before - work. What makes polymorphic relations difficult? How does Fibery represent all the users’ different types in a database? What kind of database are you using?

Anyways, I’d love to pick your brain. If you’re ever trying to solve difficult technical challenges, I’d love to pitch in!

Thanks!

1 Like

It appeared we need Polymorphic relations for References 2.0 features. So there is a chance that we will add them this year. However, with some limitations (like up to 5 databases on every end).

14 Likes

Please please please please pleeaase :star_struck:

3 Likes

Oh wow! How so?

That sounds like it will be a huge undertaking.