Of course not. In fact gentoo bugzilla is wrong place to put it.
We need this patch to be included in mainline, not in Gentoo
Alexey Parshin wrote:
> I've sent it to gentoo bugzilla, and it's already assigned to someone.
> Isn't it enough?
>
> http://bugs.gentoo.org/show_bug.cgi?id=155624
>
> 2006/11/20, Ilya A. Volynets-Evenbakh <ilya@total-knowledge.com
> <mailto:ilya@total-knowledge.com>>:
>
> What I want you to do, is submit the Umbrello patch to umbrello
> bugzilla
> (CC me on the bug report). Once it gets into mainline, we'll be fine.
> Before that you'll be the one taking care of SQL script.
>
> Alexey Parshin wrote:
> > It looks like my previous Umbrello patch was incomplete. The new
> > version of the patch (attached along with ebuild) does much better
> > job. I've also added more foreign keys descriptions for anything
> > surrounding person_list. Some foreign keys pointing to this table
> > aren't defined on the schema. They would be added by the final
> > generation script, since adding 'em to the schema makes it really
> > messy visually.
> >
> > Should I add these attached files to SVN? Without 'em Umbrello can't
> > generate foreign keys in SQL scripts properly.
> >
> > Alexey
> >
> > 2006/11/19, Alexey Parshin < alexeyp@gmail.com
> <mailto:alexeyp@gmail.com>
> > <mailto:alexeyp@gmail.com <mailto:alexeyp@gmail.com>>>:
> >
> > 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 <http://bugs.gentoo.org>
> <http://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
> <mailto:av@total-knowledge.com>
> > <mailto:av@total-knowledge.com
> <mailto: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
> <mailto:av@total-knowledge.com>
> > <mailto: av@total-knowledge.com
> <mailto: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 <http://total-knowledge.com>
> <http://total-knowledge.com>
> > culturedialogue.org <http://culturedialogue.org>
> <http://culturedialogue.org <http://culturedialogue.org>>
> >
> >
> >
> > Alexey Parshin wrote:
> > > 2006/11/14, Anatoly Volynets < av@total-knowledge.com
> <mailto:av@total-knowledge.com>
> > <mailto: av@total-knowledge.com
> <mailto: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 <http://total-knowledge.com> <
> http://total-knowledge.com>
> > culturedialogue.org <http://culturedialogue.org>
> <http://culturedialogue.org>
> >
> >
> >
> >
> >
> > Alexey Parshin wrote:
> > > 2006/11/14, Anatoly Volynets < av@total-knowledge.com
> <mailto:av@total-knowledge.com>
> > <mailto: av@total-knowledge.com
> <mailto: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 <http://total-knowledge.com> <
> http://total-knowledge.com>
> > culturedialogue.org <http://culturedialogue.org>
> <http://culturedialogue.org>
> >
> >
> >
> >
> > --
> > Alexey Parshin,
> > http://www.sptk.net
> >
> >
> >
> >
> > --
> > Alexey Parshin,
> > http://www.sptk.net <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) << ")";
> > + }
> > }
> > }
> >
> >
>
> --
> Ilya A. Volynets-Evenbakh
> Total Knowledge. CTO
> http://www.total-knowledge.com
>
>
>
>
> --
> Alexey Parshin,
> http://www.sptk.net <http://www.sptk.net>
--
Ilya A. Volynets-Evenbakh
Total Knowledge. CTO
http://www.total-knowledge.com