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" <[EMAIL PROTECTED]>
Jacopo,
I noticed your changes.
Thanks for taking initiative of this.
On Wed, Jul 16, 2008 at 2:04 PM, Jacopo Cappellato <
[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]>
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" <[EMAIL PROTECTED]>
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 <
[EMAIL PROTECTED]> 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 <
[EMAIL PROTECTED]
>
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
