What is best practice for table_name?

Questions
#1

In SS4, I am wondering what is best practice for table name (private static $table_name) in Data Objects.

With the introduction of name spacing you have several classes named - for example - Item. E.g. Vendor\ThingsForSale\Item and AnotherVendor\LostAndFound\Item.

It seems reasonable to add $table_name = ‘Item’ to both data objects but that is obvious not going to work. So - my question is - should we actually use $table_name in SS4 or is that only meant to tie over SS3 dataobjects into SS4 world?

What if we made the table name a bit more detailed but not the full namespacing - e.g. LostAndFoundItem? Is that bad?

Keen to hear some ideas on best practice here.

#2

Not sure about “best practice”, but I reckon adding too much details (ie the whole namespace path) to the table name is bad as explicitly stated when you dev/build, due to the table name length constraint (e.g. in MySQL, the tablename length max is 64)

For me I just use ThingsForSale_Item and LostAndFound_Item but I can see how this is problematic in that I have to be sure not to use 2 modules with the same folder/classname.

Your suggestion of detailed LostAndFoundItem like mine, would alleviate, but ultimately not solve the same problem above since Vendor\LostAndFound\Item can still map to the same table as AnotherVendor\LostAndFound\Item

Of course shortening the names used would help allow the full namespace to be used, but then it depends on our creativity of naming vs readability of the names.

I am in view that the CMS/framework should provide a way to prefix all tables of a module in its config; that way we can then resolve in our own terms the namespace conflicts (e.g I could just prefix Vendor tables with V, and AnotherVendor with AV as I like)

This has been somewhat touched upon in https://github.com/silverstripe/silverstripe-framework/issues/5591 but I am not sure if there was a pull request or if it is already in the codebase.

1 Like
#3

Hi Chee,

What an awesome, detailed answer. Thank you.

It seems you are right in your detailed analysis.

I guess if you end up having to tables with the same name you could do something in the yml files - e.g.

My\DataObject\Item:
   table_name: 'SomethingDifferent'

And that should work.

You would then have to manually move the table in your DB I am guessing …

#5

I am thinking of something less granular; suppose if i am using your module i can add this in my site config

Sunnysideup\*:
    Table_prefix: ‘ssu1’

That would be ideal and quite easy to manage

#4

I tend to use the a project reference as a prefix to help avoid potential collisions with other code, or if it’s an add-on, I’ll use a vendor prefix.

So, I might end up with something like CoolSite_Products or DorsetDigital_ModuleData

1 Like