ORM implementation

[IamPersistent]

The question of ORM has come up again. Right now, we have a couple of bundles that are using DoctrineORM for storing to a relational database. The problem really come with the Product. When you have a various types of products with an unknown amount and types of features and options, then add in an unknown number identifiers for some or none of the products and options, storage in a relational database becomes difficult.

My plan, for a while, has been to add support for PHPCR from the the SymfonyCMF project. There is a Doctrine implementation that could be used as the backend for the usual relational databases. By using the PHPCR interface, I believe it will make it easier to store products with varying features and options with the added bonus of gaining access to a number of different storage engines. I still think this is the best course of action for the project, especially for persisting the Product.

PHPCR may not be right for all of the data that needs to be persisted, but I think with persisting the Product, its the smartest way to go.

Any other thoughts?

Richard

[David Buchmann]

hi richard,

(disclaimer: i am one of the core developpers of PHPCR and this is my
biased opinion :-)

i think this is an excellent idea. for semi-structured content, PHPCR is
the right fit. you can have different model classes stored along with
each other, put them into hierarchies and have them reference each other
regardless of the target type. on the other hand, with the PHPCR-ODM and
document classes, you still don't risk a mess in your database.

PHPCR supports universally unique identifiers, which you could use in
the order information and similar. because data that you want to
aggregate and that really /is/ relational should rather live in a
relational database than in PHPCR.
while PHPCR does have search methods, they should not be overused -
performance can be less than you would expect from relational database.
it is /not/ a relational database, but a nosql-like store with tree
structures, references and - depending on whether the backend supports -
goodies like versioning.
one thing you might also enjoy is multilang: phpcr-odm has a multilang
support built in where you only need to care about language when writing
translations, but uses the request language when reading, so your code
does normally not need to be multilang aware.

with the doctrine xml/yml mapping, you can theoretically also share
model classes between the different storages. for very simple cases
(just one product class) the relational db probably is enough. but when
it gets more complex, you can switch to PHPCR and provide mappings for
that as well.

cheers,
david

Am 13.07.2012 19:22, schrieb IamPersistent:
> The question of ORM has come up again. Right now, we have a couple of
> bundles that are using DoctrineORM for storing to a relational database.
> The problem really come with the Product. When you have a various types
> of products with an unknown amount and types of features and options,
> then add in an unknown number identifiers for some or none of the
> products and options, storage in a relational database becomes difficult.
>
> My plan, for a while, has been to add support for PHPCR

> <http://phpcr.github.com/> from the the SymfonyCMF
> <http://cmf.symfony.com/> project. There is a Doctrine implementation
> <https://github.com/jackalope/jackalope-doctrine-dbal> that could be

> used as the backend for the usual relational databases. By using the
> PHPCR interface, I believe it will make it easier to store products with
> varying features and options with the added bonus of gaining access to a
> number of different storage engines. I still think this is the best
> course of action for the project, especially for persisting the Product.
>
> PHPCR may not be right for all of the data that needs to be persisted,
> but I think with persisting the Product, its the smartest way to go.
>
> Any other thoughts?
>
> Richard

--
Liip AG // Agile Web Development // T +41 26 422 25 11
CH-1700 Fribourg // PGP 0xA581808B // www.liip.ch

[Richard Shank]

Thanks for the feedback David. I may be pestering you guys for some pointer in the next few weeks :)

[David Buchmann]

of course, do ask questions :-)

one thing i forgot to mention: i recommend you decouple the actual
product model classes enough from the rest that the user can use
anything as models. (orm, phpcr-odm, propel, his own something). if
there are any required things, you could define an interface as we do
for some things in the cmf, or use an admin class as sonata admin does
(avoids enforcing anything on your model class, not even interface). and
use a repository interface that loads products (by the id they reported
- without the other part knowing anything about the nature and semantics
of that id)

cheers,david

> <tel:%2B41%2026%20422%2025%2011>
> CH-1700 Fribourg // PGP 0xA581808B // www.liip.ch <http://www.liip.ch>

[Lukas Kahwe Smith]

On Jul 16, 2012, at 2:17 AM, Richard Shank wrote:

> Thanks for the feedback David. I may be pestering you guys for some pointer in the next few weeks :)

you might also be interested in:
https://github.com/netvlies/DoctrineBridgeBundle

it was created to help reference classes between different persistent managers.

regards,
Lukas Kahwe Smith
m...@pooteeweet.org

[rmsint]

Op vrijdag 13 juli 2012 19:22:59 UTC+2 schreef IamPersistent het volgende:
> <span style="color:rgb(0,0,0);font-family:arial;font-size:small">The question of ORM has come up again. Right now, we have a couple of bundles that are using DoctrineORM for storing to a relational database. The problem really come with the Product. When you have a various types of products with an unknown amount and types of features and options, then add in an unknown number identifiers for some or none of the products and options, storage in a relational database becomes difficult.</span>
>
> <span style="color:rgb(0,0,0);font-family:arial;font-size:small">My plan, for a while, has been to add support for</span><span style="color:rgb(0,0,0);font-family:arial;font-size:small"> </span><a href="http://phpcr.github.com/" style="font-family:arial;font-size:small" target="_blank">PHPCR</a><span style="color:rgb(0,0,0);font-family:arial;font-size:small"> </span><span style="color:rgb(0,0,0);font-family:arial;font-size:small">from the the <a href="http://cmf.symfony.com/" target="_blank">SymfonyCMF</a> project. There is a</span><span style="color:rgb(0,0,0);font-family:arial;font-size:small"> </span><a href="https://github.com/jackalope/jackalope-doctrine-dbal" style="font-family:arial;font-size:small" target="_blank">Doctrine implementation</a><span style="color:rgb(0,0,0);font-family:arial;font-size:small"> </span><span style="color:rgb(0,0,0);font-family:arial;font-size:small">that could be used as the backend for the usual relational databases. By using the PHPCR interface, I believe it will make it easier to store products with varying features and options with the added bonus of gaining access to a number of different storage engines. I still think this is the best course of action for the project, especially for persisting the Product.</span>

>
> PHPCR may not be right for all of the data that needs to be persisted, but I think with persisting the Product, its the smartest way to go.
>

> <span style="color:rgb(0,0,0);font-family:arial;font-size:small">Any other thoughts?</span>
>
> </div>
> Richard</div></div>

Hi all,

I do not know Symfony CMF and Vespolina in detail (hopefully soon I will) however it sounds like a very good idea!

When thinking about the subject I could not find an answer on where product specifications will fit in. They have a direct relation with products and are for some shops used for filtering purpose. I understand the remark of dbu that search methods of PHPCR should not be overused. Maybe a search engine (like sphinx) can solve this as it will index the products, performs filtering and will return a list of ids that then can be queried against PHPCR.

Cheers,

Roel

[Richard Shank]

On Mon, Jul 16, 2012 at 10:25 AM, rmsint <rms...@gmail.com> wrote:

Hi all,

I do not know Symfony CMF and Vespolina in detail (hopefully soon I will) however it sounds like a very good idea!

When thinking about the subject I could not find an answer on where product specifications will fit in. They have a direct relation with products and are for some shops used for filtering purpose. I understand the remark of dbu that search methods of PHPCR should not be overused. Maybe a search engine (like sphinx) can solve this as it will index the products, performs filtering and will return a list of ids that then can be queried against PHPCR.

Cheers,

Roel

The searching aspect is indeed complex. In addition to what you just mentioned, there could also be a need to search by different identifiers, based on the task. For example, a customer may look for a book by the ISBN but the warehouse might look for the same book by QR Code.

Richard

[Lukas Kahwe Smith]

well to put things a bit more into perspective:
PHPCR has APIs for full text search and depending on the implementation they can be quite fast or slow. We have found f.e. Jackrabbit to perform decently fast in fairly simple queries, but drop severely on more complex ones. This is mainly due to the fact that while Jackrabbit uses the very fast Lucene indexing solution it then does filtering of the ACLs in Java in certain situations.

as for Jackalope the reference implementation of PHPCR, we currently rely on Jackrabbit's capabilities or the very slow XPath support in RDBMS. we do plan in the future to give people the option to just hook in Solr/ElasticSearch to drive the search and we will make it possible to make ACLs for read queries entirely optional or something along those lines. At that point not only should be have fast search, but we would also expose all the high level features of these solutions like facetting etc.