PHPCR-ODM Integration

[petforsberg]

Is there a chance to add, next to Doctrine ORM or Mongo DB, a PHPCR-ODM integration within the User Bundle? It'd be of very help for creating new CMS-type websites with help of Symfony CMF distribution.

[stof]

This should be very easy, given that the Doctrine integration relies on the Doctrine Common interface, so it should be a matter of providing the mapping.

However, last time I asked @lsmith77 about it (a long time ago), he told me that users should probably not be stored in PHPCR. Maybe he changed his mind in the meantime

[lsmith77]

there are cases where it makes sense .. we might even have some code for this .. I think liip.ch uses FOSUserBundle to manage users in PHPCR /cc @dbu

[dbu]

yes, we do that in liip.ch and it works fine. i would not do tens of thousands of users, but if its just a couple of cms users it works fine. you also would need to think whether you couple them to data that is shown on the website, like employees, or if you keep the account and the employee info separate. we went for separate, because far not all employees need write access to the site.

i posted a gist a while ago with the basic things. a PR on this bundle to add phpcr-odm support would be great. in addition to the gist, you would need to do the compiler pass to make doctrine aware of things: https://gist.github.com/dbu/7639476 (also check filenames again, i guess the mapping file should be named .phpcr.xml, and the repository might be provided by FOSUserBundle). also the gist is missing groups (because we do not use them for liip.ch).

[petforsberg]

"i would not do tens of thousands of users" Well, actually, thousands of users was in fact on my mind... :) Any cons when considering FOSUserBundle with use of PHPCR? I thought that using RDMBS + PHPCR (e.g. RDBMS user table + PHPCR articles table) makes performance worse. Of course I could always do something like using a field "username" in the Article PHPCR Document, and this would be the same as "Username" in the fos_user RDBMS table. But then there would be needed two separate MySQL calls (for RDBMS and PHPCR) in some cases. Having everything in PHPCR - OR - in RDBMS (not mixed) allows for load e.g. users by Article->getAuthor()->getSomeUserDocumentOrEntityField(), I guess?

[dbu]

there is a limitation on the jackrabbit side making things very inefficient if direct children of one node in the tree go towards 10'000. if you expect more than a few thousand, you want to think about some scheme to create a subtree (for example groups of the first two letters of the username). you can do this in the id generation code and would need to adjust the UserManager accordingly.

performance wise, following references leads to multiple calls to the database even when its all in PHPCR-ODM. but its of course more convenient. there has been a couple of attempts to write some "doctrine bridge" to link documents and entities, but afaik none of them got close to production ready.

another reason to go with orm is the possibility for efficient batch updating. @dantleech is working on at least bringing some UPDATE statements into the phpcr-shell, so one less reason to avoid phpcr-odm :-)

btw, if you expect each of your thousands of users to all write several articles, you need to be even more careful about the number of children in one node for the articles, think of a good tree structure...

[petforsberg]

"btw, if you expect each of your thousands of users to all write several articles, you need to be even more careful about the number of children in one node for the articles, think of a good tree structure..."

So, the main problem is a number of a direct children of a particular node (and a number of children of these children (i.e. deeper nested children than a node of interest) doesn't play any role here)?

Regarding users activity, I expected that each of these users could write quite a lot of comments (under articles or other sort of content), forum posts, personal messages and so on (but all of these shouldn't exceed 100-200... within one node). Articles within a one category (= a node as a PHPCR articles container) shouldn't be more than 1.000 I guess, perhaps even no more than 500, so probably there should be no performance issues (I hope)...

So I guess I should rather make a separate nodes for each content-type, rather than create all of them under a one category with a "article-content-type" like field in a Document. In other words, the design pattern (considering particularly performance) here is to create nodes divided into more levels, rather than having a more flat structure, with many children under a single node.

And I wonder now, how to design a blog (each user could write a post to a one common blog) or news nodes... Perhaps something like: /blog/{year}-{month}/post or /news/{year}-{month}/news-entry... It's getting more complicated than I thoght at the beginning :)

[stof]

please move such discussion to the PHPCR mailing-list (or whathever PHPCR support channel you want) as it is not related to FOSUserBundle itself

[dbu]

So, the main problem is a number of a direct children of a particular node (and a number of children of these children (i.e. deeper nested children than a node of interest) doesn't play any role here)?

exactly. you can handle large trees, especially with the jackrabbit backend. but this discussion should go to the mailinglist or phpcr-odm rather than the user bundle to not spam maintainers of this bundle ;-)

So I guess I should rather make a separate nodes for each content-type, rather than create all of them under a one category with a "article-content-type" like field in a Document. In other words, the design pattern (considering particularly performance) here is to create nodes divided into more levels, rather than having a more flat structure, with many children under a single node.

yes, exactly. try to find the natural tree structure. this can be by topics, it could also be by year/month/day, depending on what the primary access is. (but again, lets move discussion elsewhere ;-) )

[petforsberg]

Ok, we can move on :) Thanks a lot for advices, this is of very help at the moment since I'm at the writing and desigining stage still.

[lsmith77]

but the discussion is useful to have hear for documentation for anyone else interested in FOSUserBundle PHPCR ODM support. more logical to have it hear than on some mailing list

[stof]

@lsmith77 the beginning, yes. but then, it digresses much further. If the dicussion continues, I find it better to have it in a PHPCR place (eventually linking it from here) rather than having it in the FOSUserBundle issue tracker. We should keep this issue focused on integrating the bundle with FOSUserBundle if it makes sense.

so the question now is whether this should be integrated in FOSUserBundle directly. It looks like the way to store users in PHPCR actually requires some design choices which cannot really be done in the bundle itself.

[dbu]

imho it makes sense to have FOSUserBundle provide a mapping for the model and a simple implementation of the manager and repository that work fine for < 10'000 users. the doc should just mention that from this order of magnitude on you need to think more. even then, what is in this bundle can serve as an example how to do things. i would not recommend to try to provide more advanced things in this bundle, as then indeed it becomes specific design choices.

for the liip website we just have 15 users under /cms/users and no problems with a straightforward approach.

[lsmith77]

BTW https://github.com/FriendsOfSymfony/FOSUserBundle/pull/1081

[dbu]

@equimed said he is working on this, a PR hopefully should come soon.