Sub(n+2)-table not appearing nested in Database Manager

Wappler General Bugs
#1

Table process_step_translations should appear in Process -> Step as a subtable right?

image
image452Ă—895 34.8 KB

Wappler 4.8.1 Released
#2
#3

This is something also I noticed. Currently we use indeed the parent table name as prefix, but not the full parent path.

So if you have nested tables sub1, sub2, sub3 you will get sub1, sub1_sub2, sub2_sub3 as table names.

but maybe we should do the full path as you suggest? So you should get the full parent path for each child? Like sub1, sub1_sub2, sub1_sub2_sub3 ?

1 Like
#4

Makes more sense for disambiguation reasons when designing the database.

#5

Seems clear to me.

The only thing is that if you rename one of the parent tables - all nested sub tables has to be auto renamed as well - because their prefixes change …

No post variables for sub table insert
#6

If I have two parent tables called process and form and each of them have children called items it means I can’t disambiguate the grandchildren called translations as for Wappler UI both tables would be items_translations.

Hierarchy needs to be preserved.

Renaming tables is something we need to live with. Although it has a pretty simple solution from a user perspective. Ideally you would have a meta table created by Wappler that stores all these relations independently of the name chosen. But that would actually move Wappler in the direction of a Headless CMS and maybe it’s not desirable.

#7

Bummer - just implemented all this to learn that max identifier length is just

63 chars for Postgres:
https://dev.mysql.com/doc/refman/8.0/en/identifier-length.html

and 64 chars for MySQL
https://dev.mysql.com/doc/refman/8.0/en/identifier-length.html

…

#8

I’m not sure if deep nesting is actually that good of an idea to be honest. The more sub-tables you have, the more constrained horizontal space will be for showing the table names

I also don’t think it’s a good idea to construct the nested tree (solely) based on the prefixes, but rather by looking at the relationships they form

For example, in Laravel, I can say table (model) Order belongs to User, yet the table is not named “user_order”, but just “order” (unless I explicitly name the model as UserOrder)

    public function order()
    {
        return $this->belongsTo(User::class);
    }

And I’m still able to do stuff like $user->order

1 Like
#9

Yes. They are limited, but that’s independent of Wappler. I can still build a 32 level deep naming convention a_b_c_d_… :slight_smile:

If someone hits that level of depth they have other issues to address :joy:

Although this is not unheard of in huge databases.

That would be ideal indeed but costly in terms of engineering. @George wouldn’t knex schema inspector from Rijk help with this?

#10

I think most code is already there and just needs to be slightly reworked

For example, the field containing the relationship is already able to map to the associated table (maybe because we’ve set it at creation, or maybe because Wappler already gets it dynamically at schema refresh)

Therefore, we can:

loop 
for each table
 for each column
  if column type is relationship (reference)
   get the relationship table name and add to tree
#11

Well I think we found a middle way.

When creating new sub table names and those get longer than 20 chars, then will be automatically shortened by switching to the old behavior to use the direct parent table name as prefix and not the full parents path.

So now we have best of both worlds :slight_smile:

2 Likes
#12

Update is included in Wappler 4.8.0

1 Like
#13
#14