On the other hand, there won't be a much better time for a revolution..
To me the Persistence namespace makes much more sense than the current 
clutter.

-- Daniel

On Wednesday, February 20, 2013 6:09:41 AM UTC-8, dantleech wrote:
>
> I like the Persistence/PHPCR option, what would we do with repositories, 
> listeners? 
>
> Namespace for PHPCR-ODM stuff: 
>
>     1. PHPCR/Foo.php 
>
>     2. PHPCRODM/Foo.php 
>
>     3. PhpcrOdm/Foo.php 
>
> The problem with (1) is that you could potentially have some 
> persistence code which is only concerned with PHPCR and not ODM. (2) is 
> just ugly and (3) is wierd. 
>
> Namespace schemas: 
>
>     1. Persistence/{DBName}/{Object} 
>
>         Persistence/PHPCR/Blog.php 
>         Persistence/PHPCR/Post.php 
>         Persistence/PHPCR/PostRepository.php 
>
>         Persistence/ORM/Tag.php 
>         Persistence/ORM/TagListener.php 
>         Persistence/ORM/TagRepository.php 
>
>     2. Persistence/{DBName}/{ClassType}/{Object} 
>
>         Persistence/PHPCR/Document/Blog.php 
>         Persistence/PHPCR/Document/Post.php 
>         Persistence/PHPCR/Repository/PostRepository.php 
>
>         Persistence/ORM/Entity/Tag.php 
>         Persistence/ORM/Listener/TagListener.php 
>         Persistence/ORM/Repository/TagRepository.php 
>
>     3. {DocumentType|DBName}/{Object} 
>
>         PHPCR/Blog 
>         PHPCR/BlogRepository 
>         Entity/Blog 
>         Entity/BlogRepository 
>     
> (2) is the "best" but also the most tedious. (1) is a compromise, (3) 
> seems to be the way we /should/ be doing it now based on existing 
> convention. 
>
> But I think short of starting a revolution with all the other ORM 
> bundles the path of least resistance is to just rename all our Document 
> folders to PHPCR. 
>
> On Wed, Feb 20, 2013 at 01:53:13PM +0100, David Buchmann wrote: 
> > hi, 
> > 
> > i want to try to revive an old discussion [1] that never came to any 
> > conclusion: what would be the right folders for doctrine model classes? 
> > 
> > with phpcr-odm we start to see clashes between mongo-odm and phpcr-odm 
> > [2]. 
> > 
> > the thread went into a discussion that having persistence specific 
> > classes of your model goes against the whole idea of a database 
> > abstraction layer. i agree with that. unfortunately this was kind of a 
> > closing word from me: 
> > 
> > "i think we should come to an agreement for the short term future to 
> > avoid the name clashes richard brought up and improve understanding. 
> > in the long run, it would be great to find out how to further reduce 
> > persistence layer specific classes, but that won't happen overnight. (i 
> > am not saying we should not discuss it now - the sooner the better - but 
> > we still need a short term solution)" 
> > 
> > so what do we do? we could start putting our models for phpcr-odm in 
> > PhpcrDocuments or DocumentsPhpcr. that will fix the collisions and 
> > further clutter the namespaces of a bundle. 
> > 
> > or we could put them in Persistence\Phpcr and hope that orm and mongo 
> > at some point support that concept or even prefer it over the Entity / 
> > Document folders so bundles can migrate to that thing. at least with 
> > those folders we would be open for an approach that says for example 
> > all doctrines support xml/yml mappings of classes in Model plus in 
> > Persistence\{dbname} for annotations or cases where storage tech 
> > specific classes really are needed. 
> > 
> > feedback and inputs very welcome. please keep in mind that whatever 
> > the general ideas are, we do need a solution for phpcr-odm that can be 
> > implemented quick and keeps compatibility with existing doctrine orm / 
> > mongo versions. 
> > 
> > cheers,david 
> > 
> > 
> > [1] 
> > 
> https://groups.google.com/forum/#!topic/symfony-devs/BAYC8E6TGsk/discussion 
> > [2] 
> > 
> https://groups.google.com/forum/?fromgroups=#!topic/symfony-cmf-devs/5gKhe23UHD0
>  
> > -- 
> > Liip AG // Agile Web Development // T +41 26 422 25 11 
> > CH-1700 Fribourg // PGP 0xA581808B // www.liip.ch 
> > 
> > -- 
> > Liip AG // Agile Web Development // T +41 26 422 25 11 
> > CH-1700 Fribourg // PGP 0xA581808B // www.liip.ch 
> > 
> > -- 
> > -- 
> > If you want to report a vulnerability issue on Symfony, please read the 
> procedure on http://symfony.com/security 
> > 
> > You received this message because you are subscribed to the Google 
> > Groups "symfony developers" group. 
> > To post to this group, send email to 
> > [email protected]<javascript:> 
> > To unsubscribe from this group, send email to 
> > [email protected] <javascript:> 
> > For more options, visit this group at 
> > http://groups.google.com/group/symfony-devs?hl=en 
> > --- 
> > You received this message because you are subscribed to the Google 
> Groups "Symfony developers" group. 
> > To unsubscribe from this group and stop receiving emails from it, send 
> an email to [email protected] <javascript:>. 
> > For more options, visit https://groups.google.com/groups/opt_out. 
> > 
>

-- 
-- 
If you want to report a vulnerability issue on Symfony, please read the 
procedure on http://symfony.com/security

You received this message because you are subscribed to the Google
Groups "symfony developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/symfony-devs?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Symfony developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.


Reply via email to