From: Alejandro I. <ai...@ya...> - 2011-10-25 14:14:53
|
Hey Oliver, et al! I had even forgotten I had submitted a patch ;-) Somehow I never got the mails below... So we've kept using internal hacked versions. On Tue, Oct 25, 2011 at 1:31 AM, oli...@t-... <oli...@t-...> wrote: > BTW I have released dia2code 0.8.4 where the association name bug is fixed > (https://bugs.launchpad.net/ubuntu/+source/dia2code/+bug/442295) > That is awesome news my friend! I thought the project was kinda abandoned, so I'm very happy to see it alive and well!! We will start testing with 0.8.4 and start moving away slowly but surely from our internal patched versions and let you know how it goes. Eventually we would like submit a detailed how-to or similar on how we have been using DIA and dia2code for real-world UML2 and UML/SQL modeling. We feel it's a small contribution compared to how much our business depends on these tools. Thanks for the great work and for making Open Source a better place! -- Alejandro Imass > -- Oliver > > ----- Original message ----- > From: "oli...@t-..." <oli...@t-...> > To: "Germán" <ger...@ya...>, dia...@li... > Subject: Re: [Dia2code-general] Newcomer, old user, help offered, patch for SQL module 0.83 > Sent: Mon, 17 Oct 2011 22:39:25 +0200 > > On 2011-10-17, Germán <ger...@ya...> wrote: >> >> Alejandro patch(parse_diagram.patch) solves the same problem as >> that of ftdebugger. Likewise, I do not have the necessary knowledge >> on the code to decide what is the best solution. > > Okay. I looked again at Alejandro's parse_diagram.patch and I think > it is redundant to ftdebugger's patch. > >> if you used the patch of Ftdebugger, you can continue applying the patch >> from Alejandro to make use of the feature "surrogate >> keys"(generate_code_sql.patch). > > Okay, I did that: > > RCS file: /cvsroot/dia2code/dia2code/dia2code/generate_code_sql.c,v > ---------------------------- > revision 1.5 > date: 2011/10/17 20:26:54; author: okellogg; state: Exp; lines: +24 -1 > Apply generate_code_sql.patch by Alejandro Imass, see >> [...] >> 3) In generate_code_sql.c you are assuming that the FK columns have >> the same name on both sides (which is not very common), and with with >> the advent and ever-popular use of ORM technologies such as Propel >> (PHP) and DBIx::Class (Perl) the current naming convention/trend is to >> work with simple serial "surrogate keys", and FKs are 'standardized' >> to the form xxx_id where xxx is the FK table and the FK is _always_ >> "id". So in the attached patch, I check for this convention and warn >> if not being used. > ---------------------------- > >> And finally, you can apply the patch >> that fixes the problem I found. > > Yes, I did that also in generate_code_sql.c revision 1.5 > > Hope this helps, > > Oliver > > > |