[FLOW3-general] Diffrent packages with simillar models + Doctrine

[Marcus 'biesior' Biesioroff]

ellou'

W dniu 11-03-23 18:20, Karsten Dambekalns pisze:
> Hi.
>
>
> That is the manual solution, I would not put that in kickstarted models,
> though. We have the Flow3AnnotationDriver that currently creates table
> names from the unqualified class name of a model class.
>

But is it the right idea? I was working for years with T3 extensions 
where as you know every tables contains extension key as a prefix. I 
still believe it's better option than just using 'pure' model names.

IMHO, this would be some kind of 'imposed' naming convention (even for 
FLOW3 models) which could be modified if required by the application 
developer (in case of clash). What's more while package activation 
system should check if model classes contains proper and unique table 
name definition and avoid the activation in case of conflict (then 
developer can just manually adjust names to resolve the conflicts even 
by simple increasing the name: blog1_post, blog2_post etc.)

What is important this problem should be resolved no later than in FLOW3 
1.0 as it will be a base for all next applications built with FLOW3.


> We discussed this problem already, and came up with the following:
>   * inside a package, colliding names can be solved by use of @table
>   * inter-package it would suffice to prepend the package key


Other thing is 'range' of the problem. Generally I do not think if name 
space conflicts should be considered at single package (or group of 
packages from single dev.) at all. It's developer's job to keep it 
correct and there is not problem if he/she plans the application from A 
to Z, correctly.

On the other hand when we think about some kind of vendors/community 
package repository (like current TYPO3 extension repository) it would be 
deeply uncomfortable if developer could download package but had to 
modify it's code.

Unfortunately (or maybe even fortunately ;)) currently when there's a 
conflict Doctrines schema builder just ends its work and it's required 
to spent quite long time to realize what happened.

If there was used 'convention' in all packages it could be 'catchable' 
while package implementation/activation much easier.


> Given the concept of vendor namespaces, this would work as follows:
> F3\Conference\Domain\Model\Post ->  conference_post
> TYPO3\Blog\Domain\Model\Post ->  blog_post
> RobertLemke\BirdWatch\Domain\Model\Post ->  birdwatch_post
>
> A problem would still be:
> RobertLemke\Blog\Domain\Model\Post ->  blog_post

What are the plans about vendor package's repository? Maybe some other 
solution (but more complicated) is using package name/table prefix 
unique registration like in T3repo? It's lot of additional work, and as 
I think there's no time now for such step before official release.


> What to do? Is it reasonable to assume one would not use two different
> Blog packages at the same time? Might be to migrate from one to the other...
>

No it isn't, I'm just starting with FLOW3 but when we consider the whole 
TYPO3 repository we can see that's at least few ie. galleries. Probably 
it isn't good idea to name packages as GalleryByKarsten, GalleryByMarcus 
etc. (according to vendor's namespace concept) therefore it should be 
smarter way for resolving conflicts in DB.

We should consider "gee, we need to build mechanism to prevent conflicts 
with table names for newbies". On the other way system should be able to 
detect the clash and inform the application developer what is the 
easiest way to workaround it.

> Regards,
> Karsten


all the best, thanks for your work guys :)

-- 
Marcus 'biesior' Biesioroff
http://www.typo3.pl | TYPO3 Polish Community
T3CI