Bug #66425: `DataMapFactory::resolveTableName()`: `$classNameParts` limited to 6 - TYPO3 Core - TYPO3 Forge

Actions

Copy link

Bug #66425

closed

`DataMapFactory::resolveTableName()`: `$classNameParts` limited to 6

Added by Artus Kolanowski about 9 years ago. Updated over 6 years ago.

Status:

Closed

Priority:

Should have

Assignee:

Category:

Extbase

Target version:

7.3 (Packages)

Start date:

2015-04-15

Due date:

% Done:

100%

Estimated time:

TYPO3 Version:

PHP Version:

Tags:

Complexity:

no-brainer

Is Regression:

Sprint Focus:

Description

I'm currently hit a broken dataMap generated for a class with more then six parts. This leads to MySQL syntax error for all queries generated for this class:

You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '\author.* FROM tx_blog_domain_model_post_comment\author WHERE tx_blog_domain_mo' at line 1" (226 chars)

So this means currently you have only one subnamespace for your models in extbase which is insufficient IMO:

// After this only two class parts are left
namespace Vendor\Extension\Domain\Model;

// This left one possible subnamespace part open
namespace Vendor\Extension\Domain\Model;
class Foo [...]

// This is the possible maximum currently: only one subnamespace in the model
namespace Vendor\Extension\Domain\Model\Foo;
class Bar [...]

// This already leads to a MySQL syntax error
namespace Vendor\Extension\Domain\Model\Foo\Bar;
class Baz [...]

My concrete scenario is a simple blog extension with posts which have comments which have authors, so a legit naming approach is:

namespace Vendor\Blog\Domain\Model\Post\Comment;
class Author [...]

Another legit naming approach for this case could be:

namespace Vendor\Blog\Domain\Model\Post;
class CommentAuthor [...]

But that approach wont help when your model hierarchy gets deeper and also brings a general restriction for naming conventions.

So the first naming approach doesn't work because of the current implementation of \TYPO3\CMS\Extbase\Persistence\Generic\Mapper\DataMapFactory::resolveTableName():

$classNameParts = explode('\\', $className, 6);

Is there any specific reason for this restriction? And if there are no side effects could we remove this limitation?

Actions

Copy link

Updated by Markus Klein about 9 years ago

Hi!

We are not sure if changing this has any weird consequences. Maybe you can give it a shot and tell use here, whether you encounter any misbehaviours?
If it works out, can you please push your suggested change to our review system? http://wiki.typo3.org/CWT

Thanks

Actions

Copy link

Updated by Artus Kolanowski about 9 years ago

Thanks for your very fast response, I'll do that!

Actions

Copy link

Updated by Marc Bastian Heinrichs about 9 years ago

Apart from the possibility to remove the limitation, using a class name PostCommentAuthor in namespace Vendor\Extension\Domain\Model is absolutly fine.
But what is the difference to e.g. a PostAuthor? Is the author of the post comment another that for the post, e.g. when you think of the post author adding a comment as an answer for another comment?

Actions

Copy link

Updated by Artus Kolanowski about 9 years ago

I see here two parts in this discussion:

The general aspect of this limitation
The exemplary part with that simple blog stuff

Regarding the exemplary part:

We have a general guideline how to name classes and their namespaces so using PostCommentAuthor would be not really fine for us.
The authors of comments are just value objects (a triple with url,name and email) like its parent the comment itself. The author of an post instead is currently a back-end user. The reason for this design is, that we don't need any (front-end) user registration stuff, you can just fill out the comment form and that's it. Your argument about the relation to a post author which also could post a comment makes absolute sense, but I think we don't need that because comments are rarely used and I must also allow non registered user to comment by saving only a minimal set of data. So I'm not sure if it's currently really helpful to use a more complex design to bring registered and non registered users together...?

Regarding the general aspect:

Like mentioned above there might be a organisational guideline, a more complex extension with more classes and a deeper structure or a personal preference which requires that the user (of extbase) has more than one subnamespace for persistence classes. Also the namespace structure of extbase itself tends to use namespaces over larger class names and at least this is what namespaces are for, to segment the static structure. But with only one subnamespace left in the Domain/Model area is too small and a very uncommon restriction.

Actions

Copy link

Updated by Gerrit Code Review about 9 years ago

Status changed from New to Under Review

Patch set 1 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/38749

Actions

Copy link

Updated by Gerrit Code Review about 9 years ago

Patch set 2 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/38749

Actions

Copy link

Updated by Gerrit Code Review almost 9 years ago

Patch set 1 for branch TYPO3_6-2 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/39156

Actions

Copy link