AnsweredAssumed Answered

types and aspects: usability and scalability

Question asked by aweber1nj on May 18, 2012
Latest reply on May 18, 2012 by mrogers
I have been reading quite a bit (including some of Jeff's work – there's a lot of it, so I certainly can't claim to have seen it all!), and have looked through "Professional Alfresco…"

I see content modeling addressed to a moderate degree, but nothing really "deep" so far.  Forgive me for dumping these related questions into one post…but at least they're related :).

I understand how aspects cut-across the type hierarchy (very cool, and remember multiple inheritance from my C++ days - good OO concept), but am unclear whether they are "worth it" from a practical standpoint when it comes to searching and inheritance. 

For example, it appears that CMIS code would require far more complex queires to join multiple aspects to a type in order to find objects that are leveraging multiple aspects instead of old-school type-defined properties. 
I haven't looked too closely, but does the same hold for using "Advanced Search" to query a custom type?  I assume that aspects' properties would not be offered for search by default, making the user experience and/or the customization level (of the search services) more difficult?

What about automatically propogating values from parent (folder) to child (document/content subtype)?  Does this happen automatically or can it be easily coded if we're talking about the same aspect applied to both the parent and child?  The folder-to-child property synchronization (down only in my current case) is a great example of where an aspect should work well (define the aspect and apply it - probably as a mandatory aspect - to both the folder subtype and the document subtype).  But am I shooting myself in the foot because I have to do a lot of extra work to make all that easily searchable for the end-users?

Last (for now) but not least (for now ;) ), it's unclear how aspects and types scale properly.  Is it a lot more db joins and complex queries for the Alfresco repository service to put together document-objects with a few aspects also applied (almost always applied – just varying combinations of them) for display/query versus just having a "thicker" set of types (but also more copy & paste on the model design, because identical properties are defined on a folder tree as the cm:content tree)?  Are the indexes combined or outer-joined or something?

Thanks in advance for any help.  Maybe some of this is covered somewhere that I haven't found it yet.