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.
-AJ
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.
-AJ
Where to start? You ask a lot of questions.
I don't think there's a lot to choose between types and aspects when it comes to performance, the real differentiator should be how they relate to your business objects. If you find that your model "just works" then that's a good sign, equally if there's lots of difficulty and work-arounds that's a warning that something is not quite right.
Values are not copied from parent to child, except for a few application special cases. (Can't think of any off the top of my head, but I've done it a few times.) Equally there are a few special cases where you can join data at the database level.
I understand from Andy that SOLR should allow FTS to support arbitary join quireies, however last I heard it was not quite on the roadmap.
I don't think there's a lot to choose between types and aspects when it comes to performance, the real differentiator should be how they relate to your business objects. If you find that your model "just works" then that's a good sign, equally if there's lots of difficulty and work-arounds that's a warning that something is not quite right.
Values are not copied from parent to child, except for a few application special cases. (Can't think of any off the top of my head, but I've done it a few times.) Equally there are a few special cases where you can join data at the database level.
I understand from Andy that SOLR should allow FTS to support arbitary join quireies, however last I heard it was not quite on the roadmap.
