Anyway I’m trying to manipulate the pivot table with:
$leftMenu = LeftMenu::get_by_id($id);
// How do I set the memberID??
$members = $leftMenu->Members();
$members->LeftMenuID = $AppId;
$members->write();
...
What I am trying to acheive is insert, update and delete on the leftmenu_members pivot table.
The indexes were just an attempt to add a unique constraint on VsMemberIND field
I need smth like:
ALTER TABLE `members` ADD UNIQUE (`VsMemberIND`);
As for the leftmenu - each member has multiple left menu items available.
I would like to sync (insert, update, delete) the leftmenu_members pivot table.
And I need the constraint on the leftmenu_members table too.
I need smth like:
ALTER TABLE `leftmenu_members` ADD UNIQUE (`LeftMenuID`,`MemberID`);
Adding indexes to the model is fair enough, but the issue you might find with doing it that way is validation. Adding a unique index at the database level may run into issues in the CMS when you’re editing records.
Instead, you may be better off looking at model validation to ensure that the field is set and unique, so you can display some informative error messages in the CMS.
Are there a lot of different menu items? If not, then it might be worth looking at permissions / groups to decide which menu options to show/hide. All the controls to manage this are already in the CMS, and it would avoid you having to do the extra database work yourself.
The $belongs_many_many relation would be set in Member class. As I originally understood. The class is defined in \vendor\silverstripe\framework\src\Security\Member.php which is written during composer update.
Is there an option to add or overwrite this like Wordpress does with child-theme? Just for the analogy.
Yes, and you are already doing this with your MyMemberExtension class.
As a side note: $belongs_many_many is not required, it just gives you the $supporter->Supports() method (in the above example) to quickly access all teams supported by a specific supporter. In your case it will give you all LeftMenu linked to a specific Member.
Just so I understand fully
If I extend a class through DataExtension like in my example class MyMemberExtension extends DataExtension
I can add/edit - use ORM
If I extend a class from DataObject class LeftMenu extends DataObject
then I cannot?
I think the relation LeftMenu => Member will come in handy down the line.
Any Silverstripe model has DataObject in its hierarcy. DataExtension provides just a way to extend a model without subclassing it, and this comes in handy in some situation, most notably when the model is already used by some code that you cannot modify (e.g. the Member class).