Question related to use of WorkEffortAssoc entity in OFBiz.
Locked
Question related to use of WorkEffortAssoc entity in OFBiz.
 
|
Hello All,
We have *WorkEffort* Entity in OFBiz in which we maintain a recursive relation ship using attribute *parentWorkEffortId.* Here we again have the *WorkEffortAssoc *in which we again relate two workeffort by using the *workEffortFrom *and* workEffortTo.* Now my question is like that, if we have a relationship to relate the workEffortId by it self ( i.e by an another workEffortId ), then why we need the *WorkEffortAssoc *for the same purpose. *Or it is for handeling a different scenario in (OFBiz Work Effort Data Modeling). ** * *Thanks and Regards [Rishi Solanki]* |
Re: Question related to use of WorkEffortAssoc entity in OFBiz.
|
|
Can anybody having good insight on WorkEffort module put some comments to
understand this scenario ? I am also interested to know about it. Thanks !!! On Sat, Jun 14, 2008 at 8:46 PM, Rishi Solanki <[hidden email]> wrote: > Hello All, > > We have *WorkEffort* Entity in OFBiz in which we maintain a recursive > relation ship using attribute *parentWorkEffortId.* > Here we again have the *WorkEffortAssoc *in which we again relate two > workeffort by using the *workEffortFrom *and* workEffortTo.* > Now my question is like that, if we have a relationship to relate the > workEffortId by it self ( i.e by an another workEffortId ), then why we > need > the > *WorkEffortAssoc *for the same purpose. > > *Or it is for handeling a different scenario in (OFBiz Work Effort Data > Modeling). > ** > * > *Thanks and Regards > [Rishi Solanki]* > -- Ashish Vijaywargiya Indore, India http://en.wikipedia.org/wiki/Indore |
Re: Question related to use of WorkEffortAssoc entity in OFBiz.
|
|
I have to admit that I don't like very much the workEffortParentId
field and the way it is used; it would be better if the WorkEffortAssoc entity was used every time you have to specify an association between work effort: in this way you'll have the ability to set the type ofassociation and also validity dates. Sometimes having denormalized fields is useful (to speed up queries and simplify code) but unfortunately the workEffortParentId field is not used only for this and it is used a lot, especially by the manufacturing component, ven when the WorkEffortAssoc would do much more sense. My general suggestion would be that of using WorkEffortAssoc as much as possible (especially for new code/features). Jacopo On Jul 15, 2008, at 11:46 AM, Ashish Vijaywargiya wrote: > Can anybody having good insight on WorkEffort module put some > comments to > understand this scenario ? > I am also interested to know about it. > > Thanks !!! > > > On Sat, Jun 14, 2008 at 8:46 PM, Rishi Solanki <[hidden email] > > > wrote: > >> Hello All, >> >> We have *WorkEffort* Entity in OFBiz in which we maintain a recursive >> relation ship using attribute *parentWorkEffortId.* >> Here we again have the *WorkEffortAssoc *in which we again relate two >> workeffort by using the *workEffortFrom *and* workEffortTo.* >> Now my question is like that, if we have a relationship to relate the >> workEffortId by it self ( i.e by an another workEffortId ), then >> why we >> need >> the >> *WorkEffortAssoc *for the same purpose. >> >> *Or it is for handeling a different scenario in (OFBiz Work Effort >> Data >> Modeling). >> ** >> * >> *Thanks and Regards >> [Rishi Solanki]* >> > > > > -- > Ashish Vijaywargiya > Indore, India > http://en.wikipedia.org/wiki/Indore |
smime.p7s (3K)
Re: Question related to use of WorkEffortAssoc entity in OFBiz.
|
|
Thanks Jacopo for your comments.
Let's see what other has to say about workEffortParentId field. On Tue, Jul 15, 2008 at 3:51 PM, Jacopo Cappellato < [hidden email]> wrote: > I have to admit that I don't like very much the workEffortParentId field > and the way it is used; it would be better if the WorkEffortAssoc entity was > used every time you have to specify an association between work effort: in > this way you'll have the ability to set the type ofassociation and also > validity dates. > Sometimes having denormalized fields is useful (to speed up queries and > simplify code) but unfortunately the workEffortParentId field is not used > only for this and it is used a lot, especially by the manufacturing > component, ven when the WorkEffortAssoc would do much more sense. > > My general suggestion would be that of using WorkEffortAssoc as much as > possible (especially for new code/features). > > Jacopo > > > > On Jul 15, 2008, at 11:46 AM, Ashish Vijaywargiya wrote: > > Can anybody having good insight on WorkEffort module put some comments to >> understand this scenario ? >> I am also interested to know about it. >> >> Thanks !!! >> >> >> On Sat, Jun 14, 2008 at 8:46 PM, Rishi Solanki <[hidden email]> >> wrote: >> >> Hello All, >>> >>> We have *WorkEffort* Entity in OFBiz in which we maintain a recursive >>> relation ship using attribute *parentWorkEffortId.* >>> Here we again have the *WorkEffortAssoc *in which we again relate two >>> workeffort by using the *workEffortFrom *and* workEffortTo.* >>> Now my question is like that, if we have a relationship to relate the >>> workEffortId by it self ( i.e by an another workEffortId ), then why we >>> need >>> the >>> *WorkEffortAssoc *for the same purpose. >>> >>> *Or it is for handeling a different scenario in (OFBiz Work Effort Data >>> Modeling). >>> ** >>> * >>> *Thanks and Regards >>> [Rishi Solanki]* >>> >>> >> >> >> -- >> Ashish Vijaywargiya >> Indore, India >> http://en.wikipedia.org/wiki/Indore >> > > -- Ashish Vijaywargiya Indore, India http://en.wikipedia.org/wiki/Indore |
Re: Question related to use of WorkEffortAssoc entity in OFBiz.
Administrator
|
Hi Ashish,
From: "Ashish Vijaywargiya" <[hidden email]> > Thanks Jacopo for your comments. > Let's see what other has to say about workEffortParentId field. It's crystal clear to me : I agree with Jacopo. Maybe we should even add a comment at each denormalised field (in model) to explain and make this more clear (maybe it's ealready done I did not check) Jacques > > On Tue, Jul 15, 2008 at 3:51 PM, Jacopo Cappellato < > [hidden email]> wrote: > >> I have to admit that I don't like very much the workEffortParentId field >> and the way it is used; it would be better if the WorkEffortAssoc entity was >> used every time you have to specify an association between work effort: in >> this way you'll have the ability to set the type ofassociation and also >> validity dates. >> Sometimes having denormalized fields is useful (to speed up queries and >> simplify code) but unfortunately the workEffortParentId field is not used >> only for this and it is used a lot, especially by the manufacturing >> component, ven when the WorkEffortAssoc would do much more sense. >> >> My general suggestion would be that of using WorkEffortAssoc as much as >> possible (especially for new code/features). >> >> Jacopo >> >> >> >> On Jul 15, 2008, at 11:46 AM, Ashish Vijaywargiya wrote: >> >> Can anybody having good insight on WorkEffort module put some comments to >>> understand this scenario ? >>> I am also interested to know about it. >>> >>> Thanks !!! >>> >>> >>> On Sat, Jun 14, 2008 at 8:46 PM, Rishi Solanki <[hidden email]> >>> wrote: >>> >>> Hello All, >>>> >>>> We have *WorkEffort* Entity in OFBiz in which we maintain a recursive >>>> relation ship using attribute *parentWorkEffortId.* >>>> Here we again have the *WorkEffortAssoc *in which we again relate two >>>> workeffort by using the *workEffortFrom *and* workEffortTo.* >>>> Now my question is like that, if we have a relationship to relate the >>>> workEffortId by it self ( i.e by an another workEffortId ), then why we >>>> need >>>> the >>>> *WorkEffortAssoc *for the same purpose. >>>> >>>> *Or it is for handeling a different scenario in (OFBiz Work Effort Data >>>> Modeling). >>>> ** >>>> * >>>> *Thanks and Regards >>>> [Rishi Solanki]* >>>> >>>> >>> >>> >>> -- >>> Ashish Vijaywargiya >>> Indore, India >>> http://en.wikipedia.org/wiki/Indore >>> >> >> > > > -- > Ashish Vijaywargiya > Indore, India > http://en.wikipedia.org/wiki/Indore > |
Re: Question related to use of WorkEffortAssoc entity in OFBiz.
|
|
In reply to this post by Ashish Vijaywargiya
Just like with Product and ProductCategory going through ProductCategoryMember, when two WorkEfforts are associated they should always go through WorkEffortAssoc. I don't know why the decision was made in the Project Manager specialpurpose application to use the workEffortParentId, but it shouldn't have been used there. You'll notice in the workeffort component and webapp for the child WorkEffort tree it uses the WorkEffortAssoc, and that is how it should be. Just as with products and categories the use of this direct fields is for going in the other direction, in other words when going up the tree when you want a single WorkEffort record. When going down the tree you should always use WorkEffortAssoc (just like you would always use ProductCategoryRollup). When going up the tree and you want the multiple parents always use WorkEffortAssoc. When you want to specify one of the various parent WorkEfforts already setup in WorkEffortAssoc that is the primary parent or the like then use the workEffortParentId. -David On Jul 15, 2008, at 4:35 AM, Ashish Vijaywargiya wrote: > Thanks Jacopo for your comments. > Let's see what other has to say about workEffortParentId field. > > > On Tue, Jul 15, 2008 at 3:51 PM, Jacopo Cappellato < > [hidden email]> wrote: > >> I have to admit that I don't like very much the workEffortParentId >> field >> and the way it is used; it would be better if the WorkEffortAssoc >> entity was >> used every time you have to specify an association between work >> effort: in >> this way you'll have the ability to set the type ofassociation and >> also >> validity dates. >> Sometimes having denormalized fields is useful (to speed up queries >> and >> simplify code) but unfortunately the workEffortParentId field is >> not used >> only for this and it is used a lot, especially by the manufacturing >> component, ven when the WorkEffortAssoc would do much more sense. >> >> My general suggestion would be that of using WorkEffortAssoc as >> much as >> possible (especially for new code/features). >> >> Jacopo >> >> >> >> On Jul 15, 2008, at 11:46 AM, Ashish Vijaywargiya wrote: >> >> Can anybody having good insight on WorkEffort module put some >> comments to >>> understand this scenario ? >>> I am also interested to know about it. >>> >>> Thanks !!! >>> >>> >>> On Sat, Jun 14, 2008 at 8:46 PM, Rishi Solanki <[hidden email] >>> > >>> wrote: >>> >>> Hello All, >>>> >>>> We have *WorkEffort* Entity in OFBiz in which we maintain a >>>> recursive >>>> relation ship using attribute *parentWorkEffortId.* >>>> Here we again have the *WorkEffortAssoc *in which we again relate >>>> two >>>> workeffort by using the *workEffortFrom *and* workEffortTo.* >>>> Now my question is like that, if we have a relationship to relate >>>> the >>>> workEffortId by it self ( i.e by an another workEffortId ), then >>>> why we >>>> need >>>> the >>>> *WorkEffortAssoc *for the same purpose. >>>> >>>> *Or it is for handeling a different scenario in (OFBiz Work >>>> Effort Data >>>> Modeling). >>>> ** >>>> * >>>> *Thanks and Regards >>>> [Rishi Solanki]* >>>> >>>> >>> >>> >>> -- >>> Ashish Vijaywargiya >>> Indore, India >>> http://en.wikipedia.org/wiki/Indore >>> >> >> > > > -- > Ashish Vijaywargiya > Indore, India > http://en.wikipedia.org/wiki/Indore |
Re: Question related to use of WorkEffortAssoc entity in OFBiz.
|
|
I totally agree.
Unfortunately in the manufacturing component it is even worse than this: the parentId is used for some of the associations (if I am not wrong, between a production run and its tasks) while the WorkEffortAssoc is used for others (routing to routing tasks associations, etc...); this has been done in this way in the early days of the manufacturing component and it should really fixed... I hope to find some time to work on it in the few weeks/months. Jacopo On Jul 15, 2008, at 6:15 PM, David E Jones wrote: > > Just like with Product and ProductCategory going through > ProductCategoryMember, when two WorkEfforts are associated they > should always go through WorkEffortAssoc. > > I don't know why the decision was made in the Project Manager > specialpurpose application to use the workEffortParentId, but it > shouldn't have been used there. You'll notice in the workeffort > component and webapp for the child WorkEffort tree it uses the > WorkEffortAssoc, and that is how it should be. > > Just as with products and categories the use of this direct fields > is for going in the other direction, in other words when going up > the tree when you want a single WorkEffort record. When going down > the tree you should always use WorkEffortAssoc (just like you would > always use ProductCategoryRollup). When going up the tree and you > want the multiple parents always use WorkEffortAssoc. When you want > to specify one of the various parent WorkEfforts already setup in > WorkEffortAssoc that is the primary parent or the like then use the > workEffortParentId. > > -David > > > On Jul 15, 2008, at 4:35 AM, Ashish Vijaywargiya wrote: > >> Thanks Jacopo for your comments. >> Let's see what other has to say about workEffortParentId field. >> >> >> On Tue, Jul 15, 2008 at 3:51 PM, Jacopo Cappellato < >> [hidden email]> wrote: >> >>> I have to admit that I don't like very much the workEffortParentId >>> field >>> and the way it is used; it would be better if the WorkEffortAssoc >>> entity was >>> used every time you have to specify an association between work >>> effort: in >>> this way you'll have the ability to set the type ofassociation and >>> also >>> validity dates. >>> Sometimes having denormalized fields is useful (to speed up >>> queries and >>> simplify code) but unfortunately the workEffortParentId field is >>> not used >>> only for this and it is used a lot, especially by the manufacturing >>> component, ven when the WorkEffortAssoc would do much more sense. >>> >>> My general suggestion would be that of using WorkEffortAssoc as >>> much as >>> possible (especially for new code/features). >>> >>> Jacopo >>> >>> >>> >>> On Jul 15, 2008, at 11:46 AM, Ashish Vijaywargiya wrote: >>> >>> Can anybody having good insight on WorkEffort module put some >>> comments to >>>> understand this scenario ? >>>> I am also interested to know about it. >>>> >>>> Thanks !!! >>>> >>>> >>>> On Sat, Jun 14, 2008 at 8:46 PM, Rishi Solanki <[hidden email] >>>> > >>>> wrote: >>>> >>>> Hello All, >>>>> >>>>> We have *WorkEffort* Entity in OFBiz in which we maintain a >>>>> recursive >>>>> relation ship using attribute *parentWorkEffortId.* >>>>> Here we again have the *WorkEffortAssoc *in which we again >>>>> relate two >>>>> workeffort by using the *workEffortFrom *and* workEffortTo.* >>>>> Now my question is like that, if we have a relationship to >>>>> relate the >>>>> workEffortId by it self ( i.e by an another workEffortId ), then >>>>> why we >>>>> need >>>>> the >>>>> *WorkEffortAssoc *for the same purpose. >>>>> >>>>> *Or it is for handeling a different scenario in (OFBiz Work >>>>> Effort Data >>>>> Modeling). >>>>> ** >>>>> * >>>>> *Thanks and Regards >>>>> [Rishi Solanki]* >>>>> >>>>> >>>> >>>> >>>> -- >>>> Ashish Vijaywargiya >>>> Indore, India >>>> http://en.wikipedia.org/wiki/Indore >>>> >>> >>> >> >> >> -- >> Ashish Vijaywargiya >> Indore, India >> http://en.wikipedia.org/wiki/Indore > |
Re: Question related to use of WorkEffortAssoc entity in OFBiz.
|
Administrator
|
In reply to this post by David E Jones
David, All,
Should we not write something around such aspects in the best practices. I could begin by using the detailled recommandations below... David could you provide a plan to follow ? I believe it's very important for contributors to keep mains and other applications clean. Jacques From: "David E Jones" <[hidden email]> > > Just like with Product and ProductCategory going through ProductCategoryMember, when two WorkEfforts are associated they should > always go through WorkEffortAssoc. > > I don't know why the decision was made in the Project Manager specialpurpose application to use the workEffortParentId, but it > shouldn't have been used there. You'll notice in the workeffort component and webapp for the child WorkEffort tree it uses the > WorkEffortAssoc, and that is how it should be. > > Just as with products and categories the use of this direct fields is for going in the other direction, in other words when going > up the tree when you want a single WorkEffort record. When going down the tree you should always use WorkEffortAssoc (just like > you would always use ProductCategoryRollup). When going up the tree and you want the multiple parents always use > WorkEffortAssoc. When you want to specify one of the various parent WorkEfforts already setup in WorkEffortAssoc that is the > primary parent or the like then use the workEffortParentId. > > -David > > > On Jul 15, 2008, at 4:35 AM, Ashish Vijaywargiya wrote: > >> Thanks Jacopo for your comments. >> Let's see what other has to say about workEffortParentId field. >> >> >> On Tue, Jul 15, 2008 at 3:51 PM, Jacopo Cappellato < >> [hidden email]> wrote: >> >>> I have to admit that I don't like very much the workEffortParentId field >>> and the way it is used; it would be better if the WorkEffortAssoc entity was >>> used every time you have to specify an association between work effort: in >>> this way you'll have the ability to set the type ofassociation and also >>> validity dates. >>> Sometimes having denormalized fields is useful (to speed up queries and >>> simplify code) but unfortunately the workEffortParentId field is not used >>> only for this and it is used a lot, especially by the manufacturing >>> component, ven when the WorkEffortAssoc would do much more sense. >>> >>> My general suggestion would be that of using WorkEffortAssoc as much as >>> possible (especially for new code/features). >>> >>> Jacopo >>> >>> >>> >>> On Jul 15, 2008, at 11:46 AM, Ashish Vijaywargiya wrote: >>> >>> Can anybody having good insight on WorkEffort module put some comments to >>>> understand this scenario ? >>>> I am also interested to know about it. >>>> >>>> Thanks !!! >>>> >>>> >>>> On Sat, Jun 14, 2008 at 8:46 PM, Rishi Solanki <[hidden email] >>>> > >>>> wrote: >>>> >>>> Hello All, >>>>> >>>>> We have *WorkEffort* Entity in OFBiz in which we maintain a recursive >>>>> relation ship using attribute *parentWorkEffortId.* >>>>> Here we again have the *WorkEffortAssoc *in which we again relate two >>>>> workeffort by using the *workEffortFrom *and* workEffortTo.* >>>>> Now my question is like that, if we have a relationship to relate the >>>>> workEffortId by it self ( i.e by an another workEffortId ), then why we >>>>> need >>>>> the >>>>> *WorkEffortAssoc *for the same purpose. >>>>> >>>>> *Or it is for handeling a different scenario in (OFBiz Work Effort Data >>>>> Modeling). >>>>> ** >>>>> * >>>>> *Thanks and Regards >>>>> [Rishi Solanki]* >>>>> >>>>> >>>> >>>> >>>> -- >>>> Ashish Vijaywargiya >>>> Indore, India >>>> http://en.wikipedia.org/wiki/Indore >>>> >>> >>> >> >> >> -- >> Ashish Vijaywargiya >> Indore, India >> http://en.wikipedia.org/wiki/Indore > |
Re: Question related to use of WorkEffortAssoc entity in OFBiz.
|
|
Jacques, We can't document every little thing. If best practices and other recommendations and guidelines are too big then we might as well not have them because no one will take the time to understand them, and even those few who read them all the way through won't be able to remember them. If you'd like to then by all means please do (this is not a centrally driven organization). Just keep in mind your target audience. If your question is really "how can we avoid this sort of conversation in the future" then I'm not really sure there is a good answer. With anything complex people really have to explore it and learn for themselves and telling them what they need to know before they realize they need to know it usually doesn't help. It just takes time for people to learn about things and understand common patterns. If anything I'd prefer people to have a good understanding of data structure theories and then converse intelligently based on that, and not have to converse at all for common situations that really need no discussion. However, most people don't have that background and can't tolerate weeks or months of study about graphs and trees and lists and sets and tables and indexes and hashes... and the differences and similarities between them... and common algorithms for working with them, and so on and so forth. I really wish EVERYONE involved with enterprise software would learn about these things. They are the foundational tools that we all work with on a daily basis and the theory and ideas around them are not really all that difficult compared with their utility and value in the things we create with them. -David On Jul 15, 2008, at 11:31 AM, Jacques Le Roux wrote: > David, All, > > Should we not write something around such aspects in the best > practices. I could begin by using the detailled recommandations > below... > David could you provide a plan to follow ? I believe it's very > important for contributors to keep mains and other applications clean. > > Jacques > > From: "David E Jones" <[hidden email]> >> >> Just like with Product and ProductCategory going through >> ProductCategoryMember, when two WorkEfforts are associated they >> should always go through WorkEffortAssoc. >> >> I don't know why the decision was made in the Project Manager >> specialpurpose application to use the workEffortParentId, but it >> shouldn't have been used there. You'll notice in the workeffort >> component and webapp for the child WorkEffort tree it uses the >> WorkEffortAssoc, and that is how it should be. >> >> Just as with products and categories the use of this direct fields >> is for going in the other direction, in other words when going up >> the tree when you want a single WorkEffort record. When going down >> the tree you should always use WorkEffortAssoc (just like you >> would always use ProductCategoryRollup). When going up the tree >> and you want the multiple parents always use WorkEffortAssoc. When >> you want to specify one of the various parent WorkEfforts already >> setup in WorkEffortAssoc that is the primary parent or the like >> then use the workEffortParentId. >> >> -David >> >> >> On Jul 15, 2008, at 4:35 AM, Ashish Vijaywargiya wrote: >> >>> Thanks Jacopo for your comments. >>> Let's see what other has to say about workEffortParentId field. >>> >>> >>> On Tue, Jul 15, 2008 at 3:51 PM, Jacopo Cappellato < >>> [hidden email]> wrote: >>> >>>> I have to admit that I don't like very much the >>>> workEffortParentId field >>>> and the way it is used; it would be better if the >>>> WorkEffortAssoc entity was >>>> used every time you have to specify an association between work >>>> effort: in >>>> this way you'll have the ability to set the type ofassociation >>>> and also >>>> validity dates. >>>> Sometimes having denormalized fields is useful (to speed up >>>> queries and >>>> simplify code) but unfortunately the workEffortParentId field is >>>> not used >>>> only for this and it is used a lot, especially by the manufacturing >>>> component, ven when the WorkEffortAssoc would do much more sense. >>>> >>>> My general suggestion would be that of using WorkEffortAssoc as >>>> much as >>>> possible (especially for new code/features). >>>> >>>> Jacopo >>>> >>>> >>>> >>>> On Jul 15, 2008, at 11:46 AM, Ashish Vijaywargiya wrote: >>>> >>>> Can anybody having good insight on WorkEffort module put some >>>> comments to >>>>> understand this scenario ? >>>>> I am also interested to know about it. >>>>> >>>>> Thanks !!! >>>>> >>>>> >>>>> On Sat, Jun 14, 2008 at 8:46 PM, Rishi Solanki <[hidden email] >>>>> > >>>>> wrote: >>>>> >>>>> Hello All, >>>>>> >>>>>> We have *WorkEffort* Entity in OFBiz in which we maintain a >>>>>> recursive >>>>>> relation ship using attribute *parentWorkEffortId.* >>>>>> Here we again have the *WorkEffortAssoc *in which we again >>>>>> relate two >>>>>> workeffort by using the *workEffortFrom *and* workEffortTo.* >>>>>> Now my question is like that, if we have a relationship to >>>>>> relate the >>>>>> workEffortId by it self ( i.e by an another workEffortId ), >>>>>> then why we >>>>>> need >>>>>> the >>>>>> *WorkEffortAssoc *for the same purpose. >>>>>> >>>>>> *Or it is for handeling a different scenario in (OFBiz Work >>>>>> Effort Data >>>>>> Modeling). >>>>>> ** >>>>>> * >>>>>> *Thanks and Regards >>>>>> [Rishi Solanki]* >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Ashish Vijaywargiya >>>>> Indore, India >>>>> http://en.wikipedia.org/wiki/Indore >>>>> >>>> >>>> >>> >>> >>> -- >>> Ashish Vijaywargiya >>> Indore, India >>> http://en.wikipedia.org/wiki/Indore > |
Re: Question related to use of WorkEffortAssoc entity in OFBiz.
|
Administrator
|
David,
From: "David E Jones" <[hidden email]> > > Jacques, > > We can't document every little thing. If best practices and other > recommendations and guidelines are too big then we might as well not > have them because no one will take the time to understand them, and > even those few who read them all the way through won't be able to > remember them. I thought about putting some organised links from bottom of Contributors Best Practice page. Hence those interested would read. I know it's not easy to remember, sometimes I have to read things twice (with often a long time between) or even more to really absorb them. Maybe because there are a lot of them. Nevertheless, I believe that having them documented is better than not. At least the Commiters should be aware of them. I'm one from 2 years and I'm still not aware of all I should be. Thanks to your repeated efforts I was able to grab most of the framework and some subtleties here and there. Really... documentation help ! > If you'd like to then by all means please do (this is not a centrally > driven organization). Just keep in mind your target audience. If your > question is really "how can we avoid this sort of conversation in the > future" then I'm not really sure there is a good answer. With anything > complex people really have to explore it and learn for themselves and > telling them what they need to know before they realize they need to > know it usually doesn't help. It just takes time for people to learn > about things and understand common patterns. Yes you are right, my father always told me the same :o) > If anything I'd prefer people to have a good understanding of data > structure theories and then converse intelligently based on that, and > not have to converse at all for common situations that really need no > discussion. However, most people don't have that background and can't > tolerate weeks or months of study about graphs and trees and lists and > sets and tables and indexes and hashes... and the differences and > similarities between them... and common algorithms for working with > them, and so on and so forth. > I really wish EVERYONE involved with enterprise software would learn > about these things. They are the foundational tools that we all work > with on a daily basis and the theory and ideas around them are not > really all that difficult compared with their utility and value in the > things we create with them. Yes I agree, and I'm missing such a detailled knowledge too, coming more from the algorithm branch of IT studies (sorry, BD always bored me, even if I liked them more viewed from the logic theory side ;o). However, to be pragmatic, I'm rather sure that pointing some details out will help people to better understand underlying concepts. Thansk for taking the time to comment. Jacques > -David > > > On Jul 15, 2008, at 11:31 AM, Jacques Le Roux wrote: > >> David, All, >> >> Should we not write something around such aspects in the best >> practices. I could begin by using the detailled recommandations >> below... >> David could you provide a plan to follow ? I believe it's very >> important for contributors to keep mains and other applications clean. >> >> Jacques >> >> From: "David E Jones" <[hidden email]> >>> >>> Just like with Product and ProductCategory going through >>> ProductCategoryMember, when two WorkEfforts are associated they >>> should always go through WorkEffortAssoc. >>> >>> I don't know why the decision was made in the Project Manager >>> specialpurpose application to use the workEffortParentId, but it >>> shouldn't have been used there. You'll notice in the workeffort >>> component and webapp for the child WorkEffort tree it uses the >>> WorkEffortAssoc, and that is how it should be. >>> >>> Just as with products and categories the use of this direct fields >>> is for going in the other direction, in other words when going up >>> the tree when you want a single WorkEffort record. When going down >>> the tree you should always use WorkEffortAssoc (just like you >>> would always use ProductCategoryRollup). When going up the tree >>> and you want the multiple parents always use WorkEffortAssoc. When >>> you want to specify one of the various parent WorkEfforts already >>> setup in WorkEffortAssoc that is the primary parent or the like >>> then use the workEffortParentId. >>> >>> -David >>> >>> >>> On Jul 15, 2008, at 4:35 AM, Ashish Vijaywargiya wrote: >>> >>>> Thanks Jacopo for your comments. >>>> Let's see what other has to say about workEffortParentId field. >>>> >>>> >>>> On Tue, Jul 15, 2008 at 3:51 PM, Jacopo Cappellato < >>>> [hidden email]> wrote: >>>> >>>>> I have to admit that I don't like very much the >>>>> workEffortParentId field >>>>> and the way it is used; it would be better if the >>>>> WorkEffortAssoc entity was >>>>> used every time you have to specify an association between work >>>>> effort: in >>>>> this way you'll have the ability to set the type ofassociation >>>>> and also >>>>> validity dates. >>>>> Sometimes having denormalized fields is useful (to speed up >>>>> queries and >>>>> simplify code) but unfortunately the workEffortParentId field is >>>>> not used >>>>> only for this and it is used a lot, especially by the manufacturing >>>>> component, ven when the WorkEffortAssoc would do much more sense. >>>>> >>>>> My general suggestion would be that of using WorkEffortAssoc as >>>>> much as >>>>> possible (especially for new code/features). >>>>> >>>>> Jacopo >>>>> >>>>> >>>>> >>>>> On Jul 15, 2008, at 11:46 AM, Ashish Vijaywargiya wrote: >>>>> >>>>> Can anybody having good insight on WorkEffort module put some >>>>> comments to >>>>>> understand this scenario ? >>>>>> I am also interested to know about it. >>>>>> >>>>>> Thanks !!! >>>>>> >>>>>> >>>>>> On Sat, Jun 14, 2008 at 8:46 PM, Rishi Solanki <[hidden email] >>>>>> > >>>>>> wrote: >>>>>> >>>>>> Hello All, >>>>>>> >>>>>>> We have *WorkEffort* Entity in OFBiz in which we maintain a >>>>>>> recursive >>>>>>> relation ship using attribute *parentWorkEffortId.* >>>>>>> Here we again have the *WorkEffortAssoc *in which we again >>>>>>> relate two >>>>>>> workeffort by using the *workEffortFrom *and* workEffortTo.* >>>>>>> Now my question is like that, if we have a relationship to >>>>>>> relate the >>>>>>> workEffortId by it self ( i.e by an another workEffortId ), >>>>>>> then why we >>>>>>> need >>>>>>> the >>>>>>> *WorkEffortAssoc *for the same purpose. >>>>>>> >>>>>>> *Or it is for handeling a different scenario in (OFBiz Work >>>>>>> Effort Data >>>>>>> Modeling). >>>>>>> ** >>>>>>> * >>>>>>> *Thanks and Regards >>>>>>> [Rishi Solanki]* >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Ashish Vijaywargiya >>>>>> Indore, India >>>>>> http://en.wikipedia.org/wiki/Indore >>>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> Ashish Vijaywargiya >>>> Indore, India >>>> http://en.wikipedia.org/wiki/Indore >> > |
Re: Question related to use of WorkEffortAssoc entity in OFBiz.
|
Administrator
|
In reply to this post by Rishi Solanki
BTW, what do you think of this message I sent to user list ?
<<Maybe we should even add a comment at each denormalised field (in model) to explain and make this more clear (maybe it's ealready done I did not check)>> It could be a good way to stop the pb at root. Thanks Jacques > David, > > From: "David E Jones" <[hidden email]> >> >> Jacques, >> >> We can't document every little thing. If best practices and other >> recommendations and guidelines are too big then we might as well not >> have them because no one will take the time to understand them, and >> even those few who read them all the way through won't be able to >> remember them. > > I thought about putting some organised links from bottom of Contributors Best Practice page. Hence those interested would read. I > know it's not easy to remember, sometimes I have to read things twice (with often a long time between) or even more to really > absorb them. Maybe because there are a lot of them. Nevertheless, I believe that having them documented is better than not. At > least the Commiters should be aware of them. I'm one from 2 years and I'm still not aware of all I should be. Thanks to your > repeated efforts I was able to grab most of the framework and some subtleties here and there. Really... documentation help ! > >> If you'd like to then by all means please do (this is not a centrally >> driven organization). Just keep in mind your target audience. If your >> question is really "how can we avoid this sort of conversation in the >> future" then I'm not really sure there is a good answer. With anything >> complex people really have to explore it and learn for themselves and >> telling them what they need to know before they realize they need to >> know it usually doesn't help. It just takes time for people to learn >> about things and understand common patterns. > > Yes you are right, my father always told me the same :o) > >> If anything I'd prefer people to have a good understanding of data >> structure theories and then converse intelligently based on that, and >> not have to converse at all for common situations that really need no >> discussion. However, most people don't have that background and can't >> tolerate weeks or months of study about graphs and trees and lists and >> sets and tables and indexes and hashes... and the differences and >> similarities between them... and common algorithms for working with >> them, and so on and so forth. >> I really wish EVERYONE involved with enterprise software would learn >> about these things. They are the foundational tools that we all work >> with on a daily basis and the theory and ideas around them are not >> really all that difficult compared with their utility and value in the >> things we create with them. > > Yes I agree, and I'm missing such a detailled knowledge too, coming more from the algorithm branch of IT studies (sorry, BD always > bored me, even if I liked them more viewed from the logic theory side ;o). However, to be pragmatic, I'm rather sure that pointing > some details out will help people to better understand underlying concepts. > > Thansk for taking the time to comment. > > Jacques > >> -David >> >> >> On Jul 15, 2008, at 11:31 AM, Jacques Le Roux wrote: >> >>> David, All, >>> >>> Should we not write something around such aspects in the best >>> practices. I could begin by using the detailled recommandations >>> below... >>> David could you provide a plan to follow ? I believe it's very >>> important for contributors to keep mains and other applications clean. >>> >>> Jacques >>> >>> From: "David E Jones" <[hidden email]> >>>> >>>> Just like with Product and ProductCategory going through >>>> ProductCategoryMember, when two WorkEfforts are associated they >>>> should always go through WorkEffortAssoc. >>>> >>>> I don't know why the decision was made in the Project Manager >>>> specialpurpose application to use the workEffortParentId, but it >>>> shouldn't have been used there. You'll notice in the workeffort >>>> component and webapp for the child WorkEffort tree it uses the >>>> WorkEffortAssoc, and that is how it should be. >>>> >>>> Just as with products and categories the use of this direct fields >>>> is for going in the other direction, in other words when going up >>>> the tree when you want a single WorkEffort record. When going down >>>> the tree you should always use WorkEffortAssoc (just like you >>>> would always use ProductCategoryRollup). When going up the tree >>>> and you want the multiple parents always use WorkEffortAssoc. When >>>> you want to specify one of the various parent WorkEfforts already >>>> setup in WorkEffortAssoc that is the primary parent or the like >>>> then use the workEffortParentId. >>>> >>>> -David >>>> >>>> >>>> On Jul 15, 2008, at 4:35 AM, Ashish Vijaywargiya wrote: >>>> >>>>> Thanks Jacopo for your comments. >>>>> Let's see what other has to say about workEffortParentId field. >>>>> >>>>> >>>>> On Tue, Jul 15, 2008 at 3:51 PM, Jacopo Cappellato < >>>>> [hidden email]> wrote: >>>>> >>>>>> I have to admit that I don't like very much the >>>>>> workEffortParentId field >>>>>> and the way it is used; it would be better if the >>>>>> WorkEffortAssoc entity was >>>>>> used every time you have to specify an association between work >>>>>> effort: in >>>>>> this way you'll have the ability to set the type ofassociation >>>>>> and also >>>>>> validity dates. >>>>>> Sometimes having denormalized fields is useful (to speed up >>>>>> queries and >>>>>> simplify code) but unfortunately the workEffortParentId field is >>>>>> not used >>>>>> only for this and it is used a lot, especially by the manufacturing >>>>>> component, ven when the WorkEffortAssoc would do much more sense. >>>>>> >>>>>> My general suggestion would be that of using WorkEffortAssoc as >>>>>> much as >>>>>> possible (especially for new code/features). >>>>>> >>>>>> Jacopo >>>>>> >>>>>> >>>>>> >>>>>> On Jul 15, 2008, at 11:46 AM, Ashish Vijaywargiya wrote: >>>>>> >>>>>> Can anybody having good insight on WorkEffort module put some >>>>>> comments to >>>>>>> understand this scenario ? >>>>>>> I am also interested to know about it. >>>>>>> >>>>>>> Thanks !!! >>>>>>> >>>>>>> >>>>>>> On Sat, Jun 14, 2008 at 8:46 PM, Rishi Solanki <[hidden email] >>>>>>> > >>>>>>> wrote: >>>>>>> >>>>>>> Hello All, >>>>>>>> >>>>>>>> We have *WorkEffort* Entity in OFBiz in which we maintain a >>>>>>>> recursive >>>>>>>> relation ship using attribute *parentWorkEffortId.* >>>>>>>> Here we again have the *WorkEffortAssoc *in which we again >>>>>>>> relate two >>>>>>>> workeffort by using the *workEffortFrom *and* workEffortTo.* >>>>>>>> Now my question is like that, if we have a relationship to >>>>>>>> relate the >>>>>>>> workEffortId by it self ( i.e by an another workEffortId ), >>>>>>>> then why we >>>>>>>> need >>>>>>>> the >>>>>>>> *WorkEffortAssoc *for the same purpose. >>>>>>>> >>>>>>>> *Or it is for handeling a different scenario in (OFBiz Work >>>>>>>> Effort Data >>>>>>>> Modeling). >>>>>>>> ** >>>>>>>> * >>>>>>>> *Thanks and Regards >>>>>>>> [Rishi Solanki]* >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Ashish Vijaywargiya >>>>>>> Indore, India >>>>>>> http://en.wikipedia.org/wiki/Indore >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Ashish Vijaywargiya >>>>> Indore, India >>>>> http://en.wikipedia.org/wiki/Indore >>> >> > |
Re: Question related to use of WorkEffortAssoc entity in OFBiz.
|
|
For now I have added a description for the workEffortParentId field in
rev. 677193 Jacopo On Jul 16, 2008, at 9:24 AM, Jacques Le Roux wrote: > BTW, what do you think of this message I sent to user list ? > > <<Maybe we should even add a comment at each denormalised field (in > model) to explain and make this more clear (maybe it's ealready done > I did not check)>> > > It could be a good way to stop the pb at root. > > Thanks > > Jacques > >> David, >> >> From: "David E Jones" <[hidden email]> >>> >>> Jacques, >>> >>> We can't document every little thing. If best practices and other >>> recommendations and guidelines are too big then we might as well not >>> have them because no one will take the time to understand them, and >>> even those few who read them all the way through won't be able to >>> remember them. >> >> I thought about putting some organised links from bottom of >> Contributors Best Practice page. Hence those interested would read. >> I know it's not easy to remember, sometimes I have to read things >> twice (with often a long time between) or even more to really >> absorb them. Maybe because there are a lot of them. Nevertheless, I >> believe that having them documented is better than not. At least >> the Commiters should be aware of them. I'm one from 2 years and I'm >> still not aware of all I should be. Thanks to your repeated efforts >> I was able to grab most of the framework and some subtleties here >> and there. Really... documentation help ! >> >>> If you'd like to then by all means please do (this is not a >>> centrally >>> driven organization). Just keep in mind your target audience. If >>> your >>> question is really "how can we avoid this sort of conversation in >>> the >>> future" then I'm not really sure there is a good answer. With >>> anything >>> complex people really have to explore it and learn for themselves >>> and >>> telling them what they need to know before they realize they need to >>> know it usually doesn't help. It just takes time for people to learn >>> about things and understand common patterns. >> >> Yes you are right, my father always told me the same :o) >> >>> If anything I'd prefer people to have a good understanding of data >>> structure theories and then converse intelligently based on that, >>> and >>> not have to converse at all for common situations that really need >>> no >>> discussion. However, most people don't have that background and >>> can't >>> tolerate weeks or months of study about graphs and trees and lists >>> and >>> sets and tables and indexes and hashes... and the differences and >>> similarities between them... and common algorithms for working with >>> them, and so on and so forth. >>> I really wish EVERYONE involved with enterprise software would learn >>> about these things. They are the foundational tools that we all work >>> with on a daily basis and the theory and ideas around them are not >>> really all that difficult compared with their utility and value in >>> the >>> things we create with them. >> >> Yes I agree, and I'm missing such a detailled knowledge too, coming >> more from the algorithm branch of IT studies (sorry, BD always >> bored me, even if I liked them more viewed from the logic theory >> side ;o). However, to be pragmatic, I'm rather sure that pointing >> some details out will help people to better understand underlying >> concepts. >> >> Thansk for taking the time to comment. >> >> Jacques >> >>> -David >>> >>> >>> On Jul 15, 2008, at 11:31 AM, Jacques Le Roux wrote: >>> >>>> David, All, >>>> >>>> Should we not write something around such aspects in the best >>>> practices. I could begin by using the detailled recommandations >>>> below... >>>> David could you provide a plan to follow ? I believe it's very >>>> important for contributors to keep mains and other applications >>>> clean. >>>> >>>> Jacques >>>> >>>> From: "David E Jones" <[hidden email]> >>>>> >>>>> Just like with Product and ProductCategory going through >>>>> ProductCategoryMember, when two WorkEfforts are associated they >>>>> should always go through WorkEffortAssoc. >>>>> >>>>> I don't know why the decision was made in the Project Manager >>>>> specialpurpose application to use the workEffortParentId, but it >>>>> shouldn't have been used there. You'll notice in the workeffort >>>>> component and webapp for the child WorkEffort tree it uses the >>>>> WorkEffortAssoc, and that is how it should be. >>>>> >>>>> Just as with products and categories the use of this direct fields >>>>> is for going in the other direction, in other words when going up >>>>> the tree when you want a single WorkEffort record. When going >>>>> down >>>>> the tree you should always use WorkEffortAssoc (just like you >>>>> would always use ProductCategoryRollup). When going up the tree >>>>> and you want the multiple parents always use WorkEffortAssoc. >>>>> When >>>>> you want to specify one of the various parent WorkEfforts already >>>>> setup in WorkEffortAssoc that is the primary parent or the like >>>>> then use the workEffortParentId. >>>>> >>>>> -David >>>>> >>>>> >>>>> On Jul 15, 2008, at 4:35 AM, Ashish Vijaywargiya wrote: >>>>> >>>>>> Thanks Jacopo for your comments. >>>>>> Let's see what other has to say about workEffortParentId field. >>>>>> >>>>>> >>>>>> On Tue, Jul 15, 2008 at 3:51 PM, Jacopo Cappellato < >>>>>> [hidden email]> wrote: >>>>>> >>>>>>> I have to admit that I don't like very much the >>>>>>> workEffortParentId field >>>>>>> and the way it is used; it would be better if the >>>>>>> WorkEffortAssoc entity was >>>>>>> used every time you have to specify an association between work >>>>>>> effort: in >>>>>>> this way you'll have the ability to set the type ofassociation >>>>>>> and also >>>>>>> validity dates. >>>>>>> Sometimes having denormalized fields is useful (to speed up >>>>>>> queries and >>>>>>> simplify code) but unfortunately the workEffortParentId field is >>>>>>> not used >>>>>>> only for this and it is used a lot, especially by the >>>>>>> manufacturing >>>>>>> component, ven when the WorkEffortAssoc would do much more >>>>>>> sense. >>>>>>> >>>>>>> My general suggestion would be that of using WorkEffortAssoc as >>>>>>> much as >>>>>>> possible (especially for new code/features). >>>>>>> >>>>>>> Jacopo >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Jul 15, 2008, at 11:46 AM, Ashish Vijaywargiya wrote: >>>>>>> >>>>>>> Can anybody having good insight on WorkEffort module put some >>>>>>> comments to >>>>>>>> understand this scenario ? >>>>>>>> I am also interested to know about it. >>>>>>>> >>>>>>>> Thanks !!! >>>>>>>> >>>>>>>> >>>>>>>> On Sat, Jun 14, 2008 at 8:46 PM, Rishi Solanki <[hidden email] >>>>>>>> > >>>>>>>> wrote: >>>>>>>> >>>>>>>> Hello All, >>>>>>>>> >>>>>>>>> We have *WorkEffort* Entity in OFBiz in which we maintain a >>>>>>>>> recursive >>>>>>>>> relation ship using attribute *parentWorkEffortId.* >>>>>>>>> Here we again have the *WorkEffortAssoc *in which we again >>>>>>>>> relate two >>>>>>>>> workeffort by using the *workEffortFrom *and* workEffortTo.* >>>>>>>>> Now my question is like that, if we have a relationship to >>>>>>>>> relate the >>>>>>>>> workEffortId by it self ( i.e by an another workEffortId ), >>>>>>>>> then why we >>>>>>>>> need >>>>>>>>> the >>>>>>>>> *WorkEffortAssoc *for the same purpose. >>>>>>>>> >>>>>>>>> *Or it is for handeling a different scenario in (OFBiz Work >>>>>>>>> Effort Data >>>>>>>>> Modeling). >>>>>>>>> ** >>>>>>>>> * >>>>>>>>> *Thanks and Regards >>>>>>>>> [Rishi Solanki]* >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Ashish Vijaywargiya >>>>>>>> Indore, India >>>>>>>> http://en.wikipedia.org/wiki/Indore >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Ashish Vijaywargiya >>>>>> Indore, India >>>>>> http://en.wikipedia.org/wiki/Indore >>>> >>> > |
Re: Question related to use of WorkEffortAssoc entity in OFBiz.
|
|
Jacopo,
I noticed your changes. Thanks for taking initiative of this. On Wed, Jul 16, 2008 at 2:04 PM, Jacopo Cappellato < [hidden email]> wrote: > For now I have added a description for the workEffortParentId field in rev. > 677193 > > Jacopo > > > On Jul 16, 2008, at 9:24 AM, Jacques Le Roux wrote: > > BTW, what do you think of this message I sent to user list ? >> >> <<Maybe we should even add a comment at each denormalised field (in model) >> to explain and make this more clear (maybe it's ealready done I did not >> check)>> >> >> It could be a good way to stop the pb at root. >> >> Thanks >> >> Jacques >> >> David, >>> >>> From: "David E Jones" <[hidden email]> >>> >>>> >>>> Jacques, >>>> >>>> We can't document every little thing. If best practices and other >>>> recommendations and guidelines are too big then we might as well not >>>> have them because no one will take the time to understand them, and >>>> even those few who read them all the way through won't be able to >>>> remember them. >>>> >>> >>> I thought about putting some organised links from bottom of Contributors >>> Best Practice page. Hence those interested would read. I know it's not easy >>> to remember, sometimes I have to read things twice (with often a long time >>> between) or even more to really absorb them. Maybe because there are a lot >>> of them. Nevertheless, I believe that having them documented is better than >>> not. At least the Commiters should be aware of them. I'm one from 2 years >>> and I'm still not aware of all I should be. Thanks to your repeated efforts >>> I was able to grab most of the framework and some subtleties here and there. >>> Really... documentation help ! >>> >>> If you'd like to then by all means please do (this is not a centrally >>>> driven organization). Just keep in mind your target audience. If your >>>> question is really "how can we avoid this sort of conversation in the >>>> future" then I'm not really sure there is a good answer. With anything >>>> complex people really have to explore it and learn for themselves and >>>> telling them what they need to know before they realize they need to >>>> know it usually doesn't help. It just takes time for people to learn >>>> about things and understand common patterns. >>>> >>> >>> Yes you are right, my father always told me the same :o) >>> >>> If anything I'd prefer people to have a good understanding of data >>>> structure theories and then converse intelligently based on that, and >>>> not have to converse at all for common situations that really need no >>>> discussion. However, most people don't have that background and can't >>>> tolerate weeks or months of study about graphs and trees and lists and >>>> sets and tables and indexes and hashes... and the differences and >>>> similarities between them... and common algorithms for working with >>>> them, and so on and so forth. >>>> I really wish EVERYONE involved with enterprise software would learn >>>> about these things. They are the foundational tools that we all work >>>> with on a daily basis and the theory and ideas around them are not >>>> really all that difficult compared with their utility and value in the >>>> things we create with them. >>>> >>> >>> Yes I agree, and I'm missing such a detailled knowledge too, coming more >>> from the algorithm branch of IT studies (sorry, BD always bored me, even if >>> I liked them more viewed from the logic theory side ;o). However, to be >>> pragmatic, I'm rather sure that pointing some details out will help people >>> to better understand underlying concepts. >>> >>> Thansk for taking the time to comment. >>> >>> Jacques >>> >>> -David >>>> >>>> >>>> On Jul 15, 2008, at 11:31 AM, Jacques Le Roux wrote: >>>> >>>> David, All, >>>>> >>>>> Should we not write something around such aspects in the best >>>>> practices. I could begin by using the detailled recommandations >>>>> below... >>>>> David could you provide a plan to follow ? I believe it's very >>>>> important for contributors to keep mains and other applications clean. >>>>> >>>>> Jacques >>>>> >>>>> From: "David E Jones" <[hidden email]> >>>>> >>>>>> >>>>>> Just like with Product and ProductCategory going through >>>>>> ProductCategoryMember, when two WorkEfforts are associated they >>>>>> should always go through WorkEffortAssoc. >>>>>> >>>>>> I don't know why the decision was made in the Project Manager >>>>>> specialpurpose application to use the workEffortParentId, but it >>>>>> shouldn't have been used there. You'll notice in the workeffort >>>>>> component and webapp for the child WorkEffort tree it uses the >>>>>> WorkEffortAssoc, and that is how it should be. >>>>>> >>>>>> Just as with products and categories the use of this direct fields >>>>>> is for going in the other direction, in other words when going up >>>>>> the tree when you want a single WorkEffort record. When going down >>>>>> the tree you should always use WorkEffortAssoc (just like you >>>>>> would always use ProductCategoryRollup). When going up the tree >>>>>> and you want the multiple parents always use WorkEffortAssoc. When >>>>>> you want to specify one of the various parent WorkEfforts already >>>>>> setup in WorkEffortAssoc that is the primary parent or the like >>>>>> then use the workEffortParentId. >>>>>> >>>>>> -David >>>>>> >>>>>> >>>>>> On Jul 15, 2008, at 4:35 AM, Ashish Vijaywargiya wrote: >>>>>> >>>>>> Thanks Jacopo for your comments. >>>>>>> Let's see what other has to say about workEffortParentId field. >>>>>>> >>>>>>> >>>>>>> On Tue, Jul 15, 2008 at 3:51 PM, Jacopo Cappellato < >>>>>>> [hidden email]> wrote: >>>>>>> >>>>>>> I have to admit that I don't like very much the >>>>>>>> workEffortParentId field >>>>>>>> and the way it is used; it would be better if the >>>>>>>> WorkEffortAssoc entity was >>>>>>>> used every time you have to specify an association between work >>>>>>>> effort: in >>>>>>>> this way you'll have the ability to set the type ofassociation >>>>>>>> and also >>>>>>>> validity dates. >>>>>>>> Sometimes having denormalized fields is useful (to speed up >>>>>>>> queries and >>>>>>>> simplify code) but unfortunately the workEffortParentId field is >>>>>>>> not used >>>>>>>> only for this and it is used a lot, especially by the manufacturing >>>>>>>> component, ven when the WorkEffortAssoc would do much more sense. >>>>>>>> >>>>>>>> My general suggestion would be that of using WorkEffortAssoc as >>>>>>>> much as >>>>>>>> possible (especially for new code/features). >>>>>>>> >>>>>>>> Jacopo >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Jul 15, 2008, at 11:46 AM, Ashish Vijaywargiya wrote: >>>>>>>> >>>>>>>> Can anybody having good insight on WorkEffort module put some >>>>>>>> comments to >>>>>>>> >>>>>>>>> understand this scenario ? >>>>>>>>> I am also interested to know about it. >>>>>>>>> >>>>>>>>> Thanks !!! >>>>>>>>> >>>>>>>>> >>>>>>>>> On Sat, Jun 14, 2008 at 8:46 PM, Rishi Solanki < >>>>>>>>> [hidden email] >>>>>>>>> > >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Hello All, >>>>>>>>> >>>>>>>>>> >>>>>>>>>> We have *WorkEffort* Entity in OFBiz in which we maintain a >>>>>>>>>> recursive >>>>>>>>>> relation ship using attribute *parentWorkEffortId.* >>>>>>>>>> Here we again have the *WorkEffortAssoc *in which we again >>>>>>>>>> relate two >>>>>>>>>> workeffort by using the *workEffortFrom *and* workEffortTo.* >>>>>>>>>> Now my question is like that, if we have a relationship to >>>>>>>>>> relate the >>>>>>>>>> workEffortId by it self ( i.e by an another workEffortId ), >>>>>>>>>> then why we >>>>>>>>>> need >>>>>>>>>> the >>>>>>>>>> *WorkEffortAssoc *for the same purpose. >>>>>>>>>> >>>>>>>>>> *Or it is for handeling a different scenario in (OFBiz Work >>>>>>>>>> Effort Data >>>>>>>>>> Modeling). >>>>>>>>>> ** >>>>>>>>>> * >>>>>>>>>> *Thanks and Regards >>>>>>>>>> [Rishi Solanki]* >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Ashish Vijaywargiya >>>>>>>>> Indore, India >>>>>>>>> http://en.wikipedia.org/wiki/Indore >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Ashish Vijaywargiya >>>>>>> Indore, India >>>>>>> http://en.wikipedia.org/wiki/Indore >>>>>>> >>>>>> >>>>> >>>> >> > -- Ashish Vijaywargiya Indore, India http://en.wikipedia.org/wiki/Indore |
Re: Question related to use of WorkEffortAssoc entity in OFBiz.
|
Administrator
|
I'd be happy to add that sort of comment on other denormalised fields, but how to know them all (or at least some to begin ;o) ?
Jacques From: "Ashish Vijaywargiya" <[hidden email]> > Jacopo, > > I noticed your changes. > Thanks for taking initiative of this. > > > On Wed, Jul 16, 2008 at 2:04 PM, Jacopo Cappellato < > [hidden email]> wrote: > >> For now I have added a description for the workEffortParentId field in rev. >> 677193 >> >> Jacopo >> >> >> On Jul 16, 2008, at 9:24 AM, Jacques Le Roux wrote: >> >> BTW, what do you think of this message I sent to user list ? >>> >>> <<Maybe we should even add a comment at each denormalised field (in model) >>> to explain and make this more clear (maybe it's ealready done I did not >>> check)>> >>> >>> It could be a good way to stop the pb at root. >>> >>> Thanks >>> >>> Jacques >>> >>> David, >>>> >>>> From: "David E Jones" <[hidden email]> >>>> >>>>> >>>>> Jacques, >>>>> >>>>> We can't document every little thing. If best practices and other >>>>> recommendations and guidelines are too big then we might as well not >>>>> have them because no one will take the time to understand them, and >>>>> even those few who read them all the way through won't be able to >>>>> remember them. >>>>> >>>> >>>> I thought about putting some organised links from bottom of Contributors >>>> Best Practice page. Hence those interested would read. I know it's not easy >>>> to remember, sometimes I have to read things twice (with often a long time >>>> between) or even more to really absorb them. Maybe because there are a lot >>>> of them. Nevertheless, I believe that having them documented is better than >>>> not. At least the Commiters should be aware of them. I'm one from 2 years >>>> and I'm still not aware of all I should be. Thanks to your repeated efforts >>>> I was able to grab most of the framework and some subtleties here and there. >>>> Really... documentation help ! >>>> >>>> If you'd like to then by all means please do (this is not a centrally >>>>> driven organization). Just keep in mind your target audience. If your >>>>> question is really "how can we avoid this sort of conversation in the >>>>> future" then I'm not really sure there is a good answer. With anything >>>>> complex people really have to explore it and learn for themselves and >>>>> telling them what they need to know before they realize they need to >>>>> know it usually doesn't help. It just takes time for people to learn >>>>> about things and understand common patterns. >>>>> >>>> >>>> Yes you are right, my father always told me the same :o) >>>> >>>> If anything I'd prefer people to have a good understanding of data >>>>> structure theories and then converse intelligently based on that, and >>>>> not have to converse at all for common situations that really need no >>>>> discussion. However, most people don't have that background and can't >>>>> tolerate weeks or months of study about graphs and trees and lists and >>>>> sets and tables and indexes and hashes... and the differences and >>>>> similarities between them... and common algorithms for working with >>>>> them, and so on and so forth. >>>>> I really wish EVERYONE involved with enterprise software would learn >>>>> about these things. They are the foundational tools that we all work >>>>> with on a daily basis and the theory and ideas around them are not >>>>> really all that difficult compared with their utility and value in the >>>>> things we create with them. >>>>> >>>> >>>> Yes I agree, and I'm missing such a detailled knowledge too, coming more >>>> from the algorithm branch of IT studies (sorry, BD always bored me, even if >>>> I liked them more viewed from the logic theory side ;o). However, to be >>>> pragmatic, I'm rather sure that pointing some details out will help people >>>> to better understand underlying concepts. >>>> >>>> Thansk for taking the time to comment. >>>> >>>> Jacques >>>> >>>> -David >>>>> >>>>> >>>>> On Jul 15, 2008, at 11:31 AM, Jacques Le Roux wrote: >>>>> >>>>> David, All, >>>>>> >>>>>> Should we not write something around such aspects in the best >>>>>> practices. I could begin by using the detailled recommandations >>>>>> below... >>>>>> David could you provide a plan to follow ? I believe it's very >>>>>> important for contributors to keep mains and other applications clean. >>>>>> >>>>>> Jacques >>>>>> >>>>>> From: "David E Jones" <[hidden email]> >>>>>> >>>>>>> >>>>>>> Just like with Product and ProductCategory going through >>>>>>> ProductCategoryMember, when two WorkEfforts are associated they >>>>>>> should always go through WorkEffortAssoc. >>>>>>> >>>>>>> I don't know why the decision was made in the Project Manager >>>>>>> specialpurpose application to use the workEffortParentId, but it >>>>>>> shouldn't have been used there. You'll notice in the workeffort >>>>>>> component and webapp for the child WorkEffort tree it uses the >>>>>>> WorkEffortAssoc, and that is how it should be. >>>>>>> >>>>>>> Just as with products and categories the use of this direct fields >>>>>>> is for going in the other direction, in other words when going up >>>>>>> the tree when you want a single WorkEffort record. When going down >>>>>>> the tree you should always use WorkEffortAssoc (just like you >>>>>>> would always use ProductCategoryRollup). When going up the tree >>>>>>> and you want the multiple parents always use WorkEffortAssoc. When >>>>>>> you want to specify one of the various parent WorkEfforts already >>>>>>> setup in WorkEffortAssoc that is the primary parent or the like >>>>>>> then use the workEffortParentId. >>>>>>> >>>>>>> -David >>>>>>> >>>>>>> >>>>>>> On Jul 15, 2008, at 4:35 AM, Ashish Vijaywargiya wrote: >>>>>>> >>>>>>> Thanks Jacopo for your comments. >>>>>>>> Let's see what other has to say about workEffortParentId field. >>>>>>>> >>>>>>>> >>>>>>>> On Tue, Jul 15, 2008 at 3:51 PM, Jacopo Cappellato < >>>>>>>> [hidden email]> wrote: >>>>>>>> >>>>>>>> I have to admit that I don't like very much the >>>>>>>>> workEffortParentId field >>>>>>>>> and the way it is used; it would be better if the >>>>>>>>> WorkEffortAssoc entity was >>>>>>>>> used every time you have to specify an association between work >>>>>>>>> effort: in >>>>>>>>> this way you'll have the ability to set the type ofassociation >>>>>>>>> and also >>>>>>>>> validity dates. >>>>>>>>> Sometimes having denormalized fields is useful (to speed up >>>>>>>>> queries and >>>>>>>>> simplify code) but unfortunately the workEffortParentId field is >>>>>>>>> not used >>>>>>>>> only for this and it is used a lot, especially by the manufacturing >>>>>>>>> component, ven when the WorkEffortAssoc would do much more sense. >>>>>>>>> >>>>>>>>> My general suggestion would be that of using WorkEffortAssoc as >>>>>>>>> much as >>>>>>>>> possible (especially for new code/features). >>>>>>>>> >>>>>>>>> Jacopo >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Jul 15, 2008, at 11:46 AM, Ashish Vijaywargiya wrote: >>>>>>>>> >>>>>>>>> Can anybody having good insight on WorkEffort module put some >>>>>>>>> comments to >>>>>>>>> >>>>>>>>>> understand this scenario ? >>>>>>>>>> I am also interested to know about it. >>>>>>>>>> >>>>>>>>>> Thanks !!! >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Sat, Jun 14, 2008 at 8:46 PM, Rishi Solanki < >>>>>>>>>> [hidden email] >>>>>>>>>> > >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> Hello All, >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> We have *WorkEffort* Entity in OFBiz in which we maintain a >>>>>>>>>>> recursive >>>>>>>>>>> relation ship using attribute *parentWorkEffortId.* >>>>>>>>>>> Here we again have the *WorkEffortAssoc *in which we again >>>>>>>>>>> relate two >>>>>>>>>>> workeffort by using the *workEffortFrom *and* workEffortTo.* >>>>>>>>>>> Now my question is like that, if we have a relationship to >>>>>>>>>>> relate the >>>>>>>>>>> workEffortId by it self ( i.e by an another workEffortId ), >>>>>>>>>>> then why we >>>>>>>>>>> need >>>>>>>>>>> the >>>>>>>>>>> *WorkEffortAssoc *for the same purpose. >>>>>>>>>>> >>>>>>>>>>> *Or it is for handeling a different scenario in (OFBiz Work >>>>>>>>>>> Effort Data >>>>>>>>>>> Modeling). >>>>>>>>>>> ** >>>>>>>>>>> * >>>>>>>>>>> *Thanks and Regards >>>>>>>>>>> [Rishi Solanki]* >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Ashish Vijaywargiya >>>>>>>>>> Indore, India >>>>>>>>>> http://en.wikipedia.org/wiki/Indore >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Ashish Vijaywargiya >>>>>>>> Indore, India >>>>>>>> http://en.wikipedia.org/wiki/Indore >>>>>>>> >>>>>>> >>>>>> >>>>> >>> >> > > > -- > Ashish Vijaywargiya > Indore, India > http://en.wikipedia.org/wiki/Indore > |
Re: Question related to use of WorkEffortAssoc entity in OFBiz.
|
|
A good one is the Product.primaryCategoryId (or similar).
There are also the Agreement.partyIdFrom/partyIdTo (this pattern is widely used in OFBiz). Off the top of my head. Jacopo On Jul 16, 2008, at 3:45 PM, Jacques Le Roux wrote: > I'd be happy to add that sort of comment on other denormalised > fields, but how to know them all (or at least some to begin ;o) ? > > Jacques > > From: "Ashish Vijaywargiya" <[hidden email]> >> Jacopo, >> I noticed your changes. >> Thanks for taking initiative of this. >> On Wed, Jul 16, 2008 at 2:04 PM, Jacopo Cappellato < >> [hidden email]> wrote: >>> For now I have added a description for the workEffortParentId >>> field in rev. >>> 677193 >>> >>> Jacopo >>> >>> >>> On Jul 16, 2008, at 9:24 AM, Jacques Le Roux wrote: >>> >>> BTW, what do you think of this message I sent to user list ? >>>> >>>> <<Maybe we should even add a comment at each denormalised field >>>> (in model) >>>> to explain and make this more clear (maybe it's ealready done I >>>> did not >>>> check)>> >>>> >>>> It could be a good way to stop the pb at root. >>>> >>>> Thanks >>>> >>>> Jacques >>>> >>>> David, >>>>> >>>>> From: "David E Jones" <[hidden email]> >>>>> >>>>>> >>>>>> Jacques, >>>>>> >>>>>> We can't document every little thing. If best practices and other >>>>>> recommendations and guidelines are too big then we might as >>>>>> well not >>>>>> have them because no one will take the time to understand them, >>>>>> and >>>>>> even those few who read them all the way through won't be able to >>>>>> remember them. >>>>>> >>>>> >>>>> I thought about putting some organised links from bottom of >>>>> Contributors >>>>> Best Practice page. Hence those interested would read. I know >>>>> it's not easy >>>>> to remember, sometimes I have to read things twice (with often a >>>>> long time >>>>> between) or even more to really absorb them. Maybe because there >>>>> are a lot >>>>> of them. Nevertheless, I believe that having them documented is >>>>> better than >>>>> not. At least the Commiters should be aware of them. I'm one >>>>> from 2 years >>>>> and I'm still not aware of all I should be. Thanks to your >>>>> repeated efforts >>>>> I was able to grab most of the framework and some subtleties >>>>> here and there. >>>>> Really... documentation help ! >>>>> >>>>> If you'd like to then by all means please do (this is not a >>>>> centrally >>>>>> driven organization). Just keep in mind your target audience. >>>>>> If your >>>>>> question is really "how can we avoid this sort of conversation >>>>>> in the >>>>>> future" then I'm not really sure there is a good answer. With >>>>>> anything >>>>>> complex people really have to explore it and learn for >>>>>> themselves and >>>>>> telling them what they need to know before they realize they >>>>>> need to >>>>>> know it usually doesn't help. It just takes time for people to >>>>>> learn >>>>>> about things and understand common patterns. >>>>>> >>>>> >>>>> Yes you are right, my father always told me the same :o) >>>>> >>>>> If anything I'd prefer people to have a good understanding of data >>>>>> structure theories and then converse intelligently based on >>>>>> that, and >>>>>> not have to converse at all for common situations that really >>>>>> need no >>>>>> discussion. However, most people don't have that background and >>>>>> can't >>>>>> tolerate weeks or months of study about graphs and trees and >>>>>> lists and >>>>>> sets and tables and indexes and hashes... and the differences and >>>>>> similarities between them... and common algorithms for working >>>>>> with >>>>>> them, and so on and so forth. >>>>>> I really wish EVERYONE involved with enterprise software would >>>>>> learn >>>>>> about these things. They are the foundational tools that we all >>>>>> work >>>>>> with on a daily basis and the theory and ideas around them are >>>>>> not >>>>>> really all that difficult compared with their utility and value >>>>>> in the >>>>>> things we create with them. >>>>>> >>>>> >>>>> Yes I agree, and I'm missing such a detailled knowledge too, >>>>> coming more >>>>> from the algorithm branch of IT studies (sorry, BD always bored >>>>> me, even if >>>>> I liked them more viewed from the logic theory side ;o). >>>>> However, to be >>>>> pragmatic, I'm rather sure that pointing some details out will >>>>> help people >>>>> to better understand underlying concepts. >>>>> >>>>> Thansk for taking the time to comment. >>>>> >>>>> Jacques >>>>> >>>>> -David >>>>>> >>>>>> >>>>>> On Jul 15, 2008, at 11:31 AM, Jacques Le Roux wrote: >>>>>> >>>>>> David, All, >>>>>>> >>>>>>> Should we not write something around such aspects in the best >>>>>>> practices. I could begin by using the detailled recommandations >>>>>>> below... >>>>>>> David could you provide a plan to follow ? I believe it's very >>>>>>> important for contributors to keep mains and other >>>>>>> applications clean. >>>>>>> >>>>>>> Jacques >>>>>>> >>>>>>> From: "David E Jones" <[hidden email]> >>>>>>> >>>>>>>> >>>>>>>> Just like with Product and ProductCategory going through >>>>>>>> ProductCategoryMember, when two WorkEfforts are associated they >>>>>>>> should always go through WorkEffortAssoc. >>>>>>>> >>>>>>>> I don't know why the decision was made in the Project Manager >>>>>>>> specialpurpose application to use the workEffortParentId, but >>>>>>>> it >>>>>>>> shouldn't have been used there. You'll notice in the workeffort >>>>>>>> component and webapp for the child WorkEffort tree it uses the >>>>>>>> WorkEffortAssoc, and that is how it should be. >>>>>>>> >>>>>>>> Just as with products and categories the use of this direct >>>>>>>> fields >>>>>>>> is for going in the other direction, in other words when >>>>>>>> going up >>>>>>>> the tree when you want a single WorkEffort record. When >>>>>>>> going down >>>>>>>> the tree you should always use WorkEffortAssoc (just like you >>>>>>>> would always use ProductCategoryRollup). When going up the >>>>>>>> tree >>>>>>>> and you want the multiple parents always use >>>>>>>> WorkEffortAssoc. When >>>>>>>> you want to specify one of the various parent WorkEfforts >>>>>>>> already >>>>>>>> setup in WorkEffortAssoc that is the primary parent or the >>>>>>>> like >>>>>>>> then use the workEffortParentId. >>>>>>>> >>>>>>>> -David >>>>>>>> >>>>>>>> >>>>>>>> On Jul 15, 2008, at 4:35 AM, Ashish Vijaywargiya wrote: >>>>>>>> >>>>>>>> Thanks Jacopo for your comments. >>>>>>>>> Let's see what other has to say about workEffortParentId >>>>>>>>> field. >>>>>>>>> >>>>>>>>> >>>>>>>>> On Tue, Jul 15, 2008 at 3:51 PM, Jacopo Cappellato < >>>>>>>>> [hidden email]> wrote: >>>>>>>>> >>>>>>>>> I have to admit that I don't like very much the >>>>>>>>>> workEffortParentId field >>>>>>>>>> and the way it is used; it would be better if the >>>>>>>>>> WorkEffortAssoc entity was >>>>>>>>>> used every time you have to specify an association between >>>>>>>>>> work >>>>>>>>>> effort: in >>>>>>>>>> this way you'll have the ability to set the type >>>>>>>>>> ofassociation >>>>>>>>>> and also >>>>>>>>>> validity dates. >>>>>>>>>> Sometimes having denormalized fields is useful (to speed up >>>>>>>>>> queries and >>>>>>>>>> simplify code) but unfortunately the workEffortParentId >>>>>>>>>> field is >>>>>>>>>> not used >>>>>>>>>> only for this and it is used a lot, especially by the >>>>>>>>>> manufacturing >>>>>>>>>> component, ven when the WorkEffortAssoc would do much more >>>>>>>>>> sense. >>>>>>>>>> >>>>>>>>>> My general suggestion would be that of using >>>>>>>>>> WorkEffortAssoc as >>>>>>>>>> much as >>>>>>>>>> possible (especially for new code/features). >>>>>>>>>> >>>>>>>>>> Jacopo >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Jul 15, 2008, at 11:46 AM, Ashish Vijaywargiya wrote: >>>>>>>>>> >>>>>>>>>> Can anybody having good insight on WorkEffort module put some >>>>>>>>>> comments to >>>>>>>>>> >>>>>>>>>>> understand this scenario ? >>>>>>>>>>> I am also interested to know about it. >>>>>>>>>>> >>>>>>>>>>> Thanks !!! >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Sat, Jun 14, 2008 at 8:46 PM, Rishi Solanki < >>>>>>>>>>> [hidden email] >>>>>>>>>>> > >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> Hello All, >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> We have *WorkEffort* Entity in OFBiz in which we maintain a >>>>>>>>>>>> recursive >>>>>>>>>>>> relation ship using attribute *parentWorkEffortId.* >>>>>>>>>>>> Here we again have the *WorkEffortAssoc *in which we again >>>>>>>>>>>> relate two >>>>>>>>>>>> workeffort by using the *workEffortFrom *and* >>>>>>>>>>>> workEffortTo.* >>>>>>>>>>>> Now my question is like that, if we have a relationship to >>>>>>>>>>>> relate the >>>>>>>>>>>> workEffortId by it self ( i.e by an another workEffortId ), >>>>>>>>>>>> then why we >>>>>>>>>>>> need >>>>>>>>>>>> the >>>>>>>>>>>> *WorkEffortAssoc *for the same purpose. >>>>>>>>>>>> >>>>>>>>>>>> *Or it is for handeling a different scenario in (OFBiz Work >>>>>>>>>>>> Effort Data >>>>>>>>>>>> Modeling). >>>>>>>>>>>> ** >>>>>>>>>>>> * >>>>>>>>>>>> *Thanks and Regards >>>>>>>>>>>> [Rishi Solanki]* >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Ashish Vijaywargiya >>>>>>>>>>> Indore, India >>>>>>>>>>> http://en.wikipedia.org/wiki/Indore >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Ashish Vijaywargiya >>>>>>>>> Indore, India >>>>>>>>> http://en.wikipedia.org/wiki/Indore >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>> >>> >> -- >> Ashish Vijaywargiya >> Indore, India >> http://en.wikipedia.org/wiki/Indore >> |
Re: Question related to use of WorkEffortAssoc entity in OFBiz.
|
Administrator
|
Thanks Jacopo,
I will begin digging this way Jacques From: "Jacopo Cappellato" <[hidden email]> >A good one is the Product.primaryCategoryId (or similar). > There are also the Agreement.partyIdFrom/partyIdTo (this pattern is > widely used in OFBiz). > > Off the top of my head. > > Jacopo > > On Jul 16, 2008, at 3:45 PM, Jacques Le Roux wrote: > >> I'd be happy to add that sort of comment on other denormalised >> fields, but how to know them all (or at least some to begin ;o) ? >> >> Jacques >> >> From: "Ashish Vijaywargiya" <[hidden email]> >>> Jacopo, >>> I noticed your changes. >>> Thanks for taking initiative of this. >>> On Wed, Jul 16, 2008 at 2:04 PM, Jacopo Cappellato < >>> [hidden email]> wrote: >>>> For now I have added a description for the workEffortParentId >>>> field in rev. >>>> 677193 >>>> >>>> Jacopo >>>> >>>> >>>> On Jul 16, 2008, at 9:24 AM, Jacques Le Roux wrote: >>>> >>>> BTW, what do you think of this message I sent to user list ? >>>>> >>>>> <<Maybe we should even add a comment at each denormalised field >>>>> (in model) >>>>> to explain and make this more clear (maybe it's ealready done I >>>>> did not >>>>> check)>> >>>>> >>>>> It could be a good way to stop the pb at root. >>>>> >>>>> Thanks >>>>> >>>>> Jacques >>>>> >>>>> David, >>>>>> >>>>>> From: "David E Jones" <[hidden email]> >>>>>> >>>>>>> >>>>>>> Jacques, >>>>>>> >>>>>>> We can't document every little thing. If best practices and other >>>>>>> recommendations and guidelines are too big then we might as >>>>>>> well not >>>>>>> have them because no one will take the time to understand them, >>>>>>> and >>>>>>> even those few who read them all the way through won't be able to >>>>>>> remember them. >>>>>>> >>>>>> >>>>>> I thought about putting some organised links from bottom of >>>>>> Contributors >>>>>> Best Practice page. Hence those interested would read. I know >>>>>> it's not easy >>>>>> to remember, sometimes I have to read things twice (with often a >>>>>> long time >>>>>> between) or even more to really absorb them. Maybe because there >>>>>> are a lot >>>>>> of them. Nevertheless, I believe that having them documented is >>>>>> better than >>>>>> not. At least the Commiters should be aware of them. I'm one >>>>>> from 2 years >>>>>> and I'm still not aware of all I should be. Thanks to your >>>>>> repeated efforts >>>>>> I was able to grab most of the framework and some subtleties >>>>>> here and there. >>>>>> Really... documentation help ! >>>>>> >>>>>> If you'd like to then by all means please do (this is not a >>>>>> centrally >>>>>>> driven organization). Just keep in mind your target audience. >>>>>>> If your >>>>>>> question is really "how can we avoid this sort of conversation >>>>>>> in the >>>>>>> future" then I'm not really sure there is a good answer. With >>>>>>> anything >>>>>>> complex people really have to explore it and learn for >>>>>>> themselves and >>>>>>> telling them what they need to know before they realize they >>>>>>> need to >>>>>>> know it usually doesn't help. It just takes time for people to >>>>>>> learn >>>>>>> about things and understand common patterns. >>>>>>> >>>>>> >>>>>> Yes you are right, my father always told me the same :o) >>>>>> >>>>>> If anything I'd prefer people to have a good understanding of data >>>>>>> structure theories and then converse intelligently based on >>>>>>> that, and >>>>>>> not have to converse at all for common situations that really >>>>>>> need no >>>>>>> discussion. However, most people don't have that background and >>>>>>> can't >>>>>>> tolerate weeks or months of study about graphs and trees and >>>>>>> lists and >>>>>>> sets and tables and indexes and hashes... and the differences and >>>>>>> similarities between them... and common algorithms for working >>>>>>> with >>>>>>> them, and so on and so forth. >>>>>>> I really wish EVERYONE involved with enterprise software would >>>>>>> learn >>>>>>> about these things. They are the foundational tools that we all >>>>>>> work >>>>>>> with on a daily basis and the theory and ideas around them are >>>>>>> not >>>>>>> really all that difficult compared with their utility and value >>>>>>> in the >>>>>>> things we create with them. >>>>>>> >>>>>> >>>>>> Yes I agree, and I'm missing such a detailled knowledge too, >>>>>> coming more >>>>>> from the algorithm branch of IT studies (sorry, BD always bored >>>>>> me, even if >>>>>> I liked them more viewed from the logic theory side ;o). >>>>>> However, to be >>>>>> pragmatic, I'm rather sure that pointing some details out will >>>>>> help people >>>>>> to better understand underlying concepts. >>>>>> >>>>>> Thansk for taking the time to comment. >>>>>> >>>>>> Jacques >>>>>> >>>>>> -David >>>>>>> >>>>>>> >>>>>>> On Jul 15, 2008, at 11:31 AM, Jacques Le Roux wrote: >>>>>>> >>>>>>> David, All, >>>>>>>> >>>>>>>> Should we not write something around such aspects in the best >>>>>>>> practices. I could begin by using the detailled recommandations >>>>>>>> below... >>>>>>>> David could you provide a plan to follow ? I believe it's very >>>>>>>> important for contributors to keep mains and other >>>>>>>> applications clean. >>>>>>>> >>>>>>>> Jacques >>>>>>>> >>>>>>>> From: "David E Jones" <[hidden email]> >>>>>>>> >>>>>>>>> >>>>>>>>> Just like with Product and ProductCategory going through >>>>>>>>> ProductCategoryMember, when two WorkEfforts are associated they >>>>>>>>> should always go through WorkEffortAssoc. >>>>>>>>> >>>>>>>>> I don't know why the decision was made in the Project Manager >>>>>>>>> specialpurpose application to use the workEffortParentId, but >>>>>>>>> it >>>>>>>>> shouldn't have been used there. You'll notice in the workeffort >>>>>>>>> component and webapp for the child WorkEffort tree it uses the >>>>>>>>> WorkEffortAssoc, and that is how it should be. >>>>>>>>> >>>>>>>>> Just as with products and categories the use of this direct >>>>>>>>> fields >>>>>>>>> is for going in the other direction, in other words when >>>>>>>>> going up >>>>>>>>> the tree when you want a single WorkEffort record. When >>>>>>>>> going down >>>>>>>>> the tree you should always use WorkEffortAssoc (just like you >>>>>>>>> would always use ProductCategoryRollup). When going up the >>>>>>>>> tree >>>>>>>>> and you want the multiple parents always use >>>>>>>>> WorkEffortAssoc. When >>>>>>>>> you want to specify one of the various parent WorkEfforts >>>>>>>>> already >>>>>>>>> setup in WorkEffortAssoc that is the primary parent or the >>>>>>>>> like >>>>>>>>> then use the workEffortParentId. >>>>>>>>> >>>>>>>>> -David >>>>>>>>> >>>>>>>>> >>>>>>>>> On Jul 15, 2008, at 4:35 AM, Ashish Vijaywargiya wrote: >>>>>>>>> >>>>>>>>> Thanks Jacopo for your comments. >>>>>>>>>> Let's see what other has to say about workEffortParentId >>>>>>>>>> field. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Tue, Jul 15, 2008 at 3:51 PM, Jacopo Cappellato < >>>>>>>>>> [hidden email]> wrote: >>>>>>>>>> >>>>>>>>>> I have to admit that I don't like very much the >>>>>>>>>>> workEffortParentId field >>>>>>>>>>> and the way it is used; it would be better if the >>>>>>>>>>> WorkEffortAssoc entity was >>>>>>>>>>> used every time you have to specify an association between >>>>>>>>>>> work >>>>>>>>>>> effort: in >>>>>>>>>>> this way you'll have the ability to set the type >>>>>>>>>>> ofassociation >>>>>>>>>>> and also >>>>>>>>>>> validity dates. >>>>>>>>>>> Sometimes having denormalized fields is useful (to speed up >>>>>>>>>>> queries and >>>>>>>>>>> simplify code) but unfortunately the workEffortParentId >>>>>>>>>>> field is >>>>>>>>>>> not used >>>>>>>>>>> only for this and it is used a lot, especially by the >>>>>>>>>>> manufacturing >>>>>>>>>>> component, ven when the WorkEffortAssoc would do much more >>>>>>>>>>> sense. >>>>>>>>>>> >>>>>>>>>>> My general suggestion would be that of using >>>>>>>>>>> WorkEffortAssoc as >>>>>>>>>>> much as >>>>>>>>>>> possible (especially for new code/features). >>>>>>>>>>> >>>>>>>>>>> Jacopo >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Jul 15, 2008, at 11:46 AM, Ashish Vijaywargiya wrote: >>>>>>>>>>> >>>>>>>>>>> Can anybody having good insight on WorkEffort module put some >>>>>>>>>>> comments to >>>>>>>>>>> >>>>>>>>>>>> understand this scenario ? >>>>>>>>>>>> I am also interested to know about it. >>>>>>>>>>>> >>>>>>>>>>>> Thanks !!! >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Sat, Jun 14, 2008 at 8:46 PM, Rishi Solanki < >>>>>>>>>>>> [hidden email] >>>>>>>>>>>> > >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> Hello All, >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> We have *WorkEffort* Entity in OFBiz in which we maintain a >>>>>>>>>>>>> recursive >>>>>>>>>>>>> relation ship using attribute *parentWorkEffortId.* >>>>>>>>>>>>> Here we again have the *WorkEffortAssoc *in which we again >>>>>>>>>>>>> relate two >>>>>>>>>>>>> workeffort by using the *workEffortFrom *and* >>>>>>>>>>>>> workEffortTo.* >>>>>>>>>>>>> Now my question is like that, if we have a relationship to >>>>>>>>>>>>> relate the >>>>>>>>>>>>> workEffortId by it self ( i.e by an another workEffortId ), >>>>>>>>>>>>> then why we >>>>>>>>>>>>> need >>>>>>>>>>>>> the >>>>>>>>>>>>> *WorkEffortAssoc *for the same purpose. >>>>>>>>>>>>> >>>>>>>>>>>>> *Or it is for handeling a different scenario in (OFBiz Work >>>>>>>>>>>>> Effort Data >>>>>>>>>>>>> Modeling). >>>>>>>>>>>>> ** >>>>>>>>>>>>> * >>>>>>>>>>>>> *Thanks and Regards >>>>>>>>>>>>> [Rishi Solanki]* >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> Ashish Vijaywargiya >>>>>>>>>>>> Indore, India >>>>>>>>>>>> http://en.wikipedia.org/wiki/Indore >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Ashish Vijaywargiya >>>>>>>>>> Indore, India >>>>>>>>>> http://en.wikipedia.org/wiki/Indore >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>> >>>> >>> -- >>> Ashish Vijaywargiya >>> Indore, India >>> http://en.wikipedia.org/wiki/Indore >>> > |
«
Return to OFBiz - User
|
1 view|%1 views
| Free forum by Nabble | Edit this page |