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.