I've updated the DB schema, and tested the SQL generation.
Here are the important things:
1) For all the foreign keys without name and roles, the direction of the association on the schema should be reversed.
2) Correct SQL generation requires the patched umbrello ebuild. I've made the patch and ebuild, and submitted 'em to bugs.gentoo.org today. Without the patch, Umbrello doesn't understand foreign keys from table to the same table, and generates empty foreign keys without table and field names.
3) The Umbrello keeps some ghost (non-existent) association in the xmi file. Fortunately, such associations don't have names, so as soon as I name all the real associations, I'd be able to clean 'em out.2006/11/14, Anatoly Volynets <av@total-knowledge.com>:
Below is an excerpt from specs (it is about UMO in general):
Generic Necessary Features
These are required by UU to create a UMO
* Author
* Title
* Reference-link on the parent UMO, if any
For example Topic - to its Course, Explanation - to its Topic and
further - to the course, etc.
* Contents - link, list of child UMOs
Regardless type of a UMO it can include other UMO's. These, in turn, are
listed in the parent UMO Contents (like a book contents). If no child
UMOs created, Contents link is hidden from students
* Keywords
Each UMO can say keywords essential to it and useful for searching for
it. A UMO can be created if at least one keyword supplied by the author.
Alexey Parshin wrote:
> 2006/11/14, Anatoly Volynets < av@total-knowledge.com>:
>>
>> Alexey Parshin wrote:
>> > 1) Fixing to all have modify and delete
>> > 2) Disagree. Keywords are references from the actual text words.
>>
>> Guys, I am totally out of mark, so, just in case: each UMO has a
>> mandatory property 'Keywords' (a list) - to be supplied at the time of
>> the UMO creation and to be used for searching. Are these features
>> reflected in the db schema?
>>
>
> Well, more or less. Currently, keyword lists are defined for:
> - topic
> - text in dialog of text
> - study problem
> - explanation
>
> For some UMOs, like dialog of texts, the keywords may be obtained by
> combining keyword lists from the children UMOs (in that case, texts).
> I'm thinking that implementation would include a set of views, one per
> UMO
> type.
>
>
My first impression: does not work this way - read specs.
--
Anatoly Volynets, Co-Founder
total-knowledge.com
culturedialogue.org
Alexey Parshin wrote:
> 2006/11/14, Anatoly Volynets < av@total-knowledge.com>:
>>
>> Alexey Parshin wrote:
>> > 1) Fixing to all have modify and delete
>> > 2) Disagree. Keywords are references from the actual text words.
>>
>> Guys, I am totally out of mark, so, just in case: each UMO has a
>> mandatory property 'Keywords' (a list) - to be supplied at the time of
>> the UMO creation and to be used for searching. Are these features
>> reflected in the db schema?
>>
>
> Well, more or less. Currently, keyword lists are defined for:
> - topic
> - text in dialog of text
> - study problem
> - explanation
>
> For some UMOs, like dialog of texts, the keywords may be obtained by
> combining keyword lists from the children UMOs (in that case, texts).
> I'm thinking that implementation would include a set of views, one per
> UMO
> type.
>
> I'm attaching the database schema picture specifically for Anatoly.
>
--
Anatoly Volynets, Co-Founder
total-knowledge.com
culturedialogue.org
Alexey Parshin wrote:
> 2006/11/14, Anatoly Volynets < av@total-knowledge.com >:
>>
>> Alexey Parshin wrote:
>> > 1) Fixing to all have modify and delete
>> > 2) Disagree. Keywords are references from the actual text words.
>>
>> Guys, I am totally out of mark, so, just in case: each UMO has a
>> mandatory property 'Keywords' (a list) - to be supplied at the time of
>> the UMO creation and to be used for searching. Are these features
>> reflected in the db schema?
>>
>
> Well, more or less. Currently, keyword lists are defined for:
> - topic
> - text in dialog of text
> - study problem
> - explanation
>
> For some UMOs, like dialog of texts, the keywords may be obtained by
> combining keyword lists from the children UMOs (in that case, texts).
> I'm thinking that implementation would include a set of views, one per
> UMO
> type.
>
> I'm attaching the database schema picture specifically for Anatoly.
>
--
Anatoly Volynets, Co-Founder
total-knowledge.com
culturedialogue.org
--
Alexey Parshin,
http://www.sptk.net
diff -uNr kdesdk-3.5.5.orig/umbrello/umbrello/codegenerators/sqlwriter.cpp kdesdk-3.5.5/umbrello/umbrello/codegenerators/sqlwriter.cpp
--- kdesdk-3.5.5.orig/umbrello/umbrello/codegenerators/sqlwriter.cpp 2006-07-22 18:11:57.000000000 +1000
+++ kdesdk-3.5.5/umbrello/umbrello/codegenerators/sqlwriter.cpp 2006-11-20 16:42:35.000000000 +1100
@@ -86,14 +86,15 @@
UMLAssociationList aggregations = c->getAggregations();
if( forceSections() || !aggregations.isEmpty() ) {
for(UMLAssociation* a = aggregations.first(); a; a = aggregations.next()) {
- if( a->getObject(Uml::A)->getID() != c->getID() ) {
-
- sql << m_indentation << "," << m_endl << m_indentation
- << "CONSTRAINT " << a->getName() << " FOREIGN KEY ("
- << a->getRoleName(Uml::B) << ") REFERENCES "
- << a->getObject(Uml::A)->getName()
- << " (" << a->getRoleName(Uml::A) << ")";
- }
+ if( a->getObject(Uml::A)->getID() == c->getID() && a->getObject(Uml::B)->getID() != c->getID() )
+ continue;
+ if ( a->getRoleName(Uml::B) != "" && a->getRoleName(Uml::B) != "") {
+ sql << m_indentation << "," << m_endl << m_indentation
+ << "CONSTRAINT " << a->getName() << " FOREIGN KEY ("
+ << a->getRoleName(Uml::B) << ") REFERENCES "
+ << a->getObject(Uml::A)->getName()
+ << " (" << a->getRoleName(Uml::A) << ")";
+ }
}
}
Attachment:
umbrello-3.5.5-r1.ebuild
Description: Binary data