I remember that discussion.... On Sun, 2013-07-07 at 19:13 +0200, Wolfgang Keller wrote:
> > > >obvious non-starter, no doubt), they talk about "developers, who > > >clearly forgot to attend CS 101 classes". > > > > > >Well, in my "CS 101 for non computer scientists" class they taught me > > >certain things that the developers behind Tryton obviously ignore. > > >And at least one of those issues is critical to data integrity To be fair, "CS 101" really wouldn't go into such "database integrity" issues--that would be more of a discussion for a CS class focused more on database design. > > > > Would be great if you can be more concrete and share the issues with > > the comunity. > > I have already done that, see: > > Message-Id: <[email protected]> See, if you were to post references to these discussions in the first place then people would be less confused and/or upset. This email mentions "database integrity" then does not mention the specific issue you had in the first place. To me that seems like the wrong approach. I understand your frustration but even if you cannot be bothered to take the time to put a reference link in your email to back your discussion at least be more specific in your email so we could do a search for ourselves. It would have even been more helpful if you had merely mentioned "composite keys". To your credit at least you provided a reference when people asked. Just be careful in the future because making specious arguments without any references (even arguments with a valid point in fact) can be construed as "trolling". > > The "response" from the developers was an obscene exhibition of their > total cluelessness and carelessness for such critical issues as data > integrity. > I do find that some people who reply on this list can be a bit terse in their responses and it can come across the wrong way. I tend to think that it is sometimes a language issue--English is the one common language of all users here but Tryton is used all over the world and its active users and developers speak a number of different languages as their mother tongues. As such I do try to give people some latitude. I also know that some very technically capable people can have difficult personalities but e best approach is not to make a discussion personal (the "OpenPSD Project" is based where I live--the founder/leader of that project is a brilliant guy but it is best not to get into "religious" discussions with him if you tend to take such matters personally). > Sincerely, > > Wolfgang Now as to the matter at hand (composite keys), I tend to favour their use at certain times where appropriate but it is one of those "religious discussions", not simply a matter of something simply being done wrong (which using float for currency transactions is). I have seen composite/natural keys being used in a simply wrong way before (stupid stuff like a table with a large number of fields and all but one "description" field is part of some huge key. If you have a table with 10 fields and 9 of them make up the primary key you are probably doing it wrong--time to re-think your schema!). On the other hand I have seen a single GUID "id" field as a PK simply because a PK is needed, but then no constraints or any enforcement of integrity done at all, which is also not good! With Tryton I haven't found data integrity to be a serious concern as it is possible to address all the needs I have had--you can create unique multi-field constraints and do one-to-one, one-to-many and many-to-many relations that are enforced at the PostgreSQL level, etc. So the question about "need" is certainly valid. I think the concern is to control feature bloat and complexity in the framework and base module distribution--OpenERP looks to have had a history of module management getting out of control and things being implemented before careful consideration of the consequences to usability, performance and reliability. One thing that would be helpful is to actually "participate" in development in the process of "complaining". If I strongly hold a certain opinion of a way of doing something I would contribute sample code even, which it seems you are very capable of doing considering the topics you discuss. If you are not a programmer, bring your specific problem to the table. If the limitations of Tryton adversely affect your ability to use it--say, you have a customer or your own business that has some application that required composite keys and so it prevents Tryton from being used--then describe that and there are people in this community that would back you up to be sure. But please do remember not to be "trollish" in you conduct--it incites discussion that I do not appreciate and gets in the way of the more useful purposes of this group. Trust me I do understand if it feels like people are being dismissive of a point you have strong beliefs in but I also understand the need to prioritise development and that everything needs to be justified before limited resources are put towards a task. And in my past project experience, especially (but not only) when non-technical people are concerned you will get absolutely nowhere by saying "because that's the way it is taught" or "look in any textbook" or "just google it and you'll see why". That may be useful in later backing up your argument but it convinces nobody at all---on ANY project--that people should spend 'x hours' or 'y dollars' to do something. Now, if you explained that "I have a million-dollar Tryton project and a module I am writing needs composite primary keys because it cannot enforce data integrity any other way" or "here is an example where the sales module would work 100% faster if we used a composite primary key" and showed the queries that Tryton issued vs. an example you had, you would absolutely NOT be dismissed as a troll--even if you were rude about it ;-) I think that is the difference between OpenERP and Tryton--the latter is a meritocracy--it seems constructive arguments are always considered and there isn't much weight put on discussions of marketing or on matters of personal preference. In the case of OpenERP some legitimate concerns are ignored even in the presence of a convincing use case or example of an issue unless you are a paid partner--while sometimes trivial things get attention. I think that is what the point of this whole thread was to start with. Now if only some people could be better at "being nice to each other" ;-) Mark.
