Le 23/09/2017 à 16:29, Ratnesh Upadhyay a écrit :
Hi Jacques,
Thanks for the response. I was thinking that retrieval gets slow down when
we have a lot of data in communication event entity. Actually, I've
prepared this proposal based on the current implementation of
CommunicationEventOrder on this assumption that it's an approved feature
that's its there in the system.
Thanks Ratnesh, I see your point now
I am also in agreement with you and Deepak to use the existing (generic)
data model to achieve this. I'll give it another thought and further
analyze it to fit in existing data model.
I finally think we can go with your proposition, following the same way than
CommunicationEventOrder, if it eases the introduction of the feature
Jacques
Thanks!!
Regards,
Ratnesh Upadhyay
HotWax Systems | www.hotwaxsystems.com
On Sat, Sep 23, 2017 at 5:37 PM, Jacques Le Roux <
[email protected]> wrote:
Le 23/09/2017 à 13:14, Ratnesh Upadhyay a écrit :
Imagine if we use the generic data model to record each kind of
communication and when the system tries to pull a specific email or
specific type email communication from this model then system has to
browse
a lot of data and due to this most of the time, it gets ended up with slow
query/browsing issue. So to avoid such performance issue instead of
extending CommunicationEvent entity, I proposed to make a separate entity.
Hi Ratnesh,
Are you sure about that? What would the bottleneck? If you think the DB
would slow down I don't think it's an issue.
My take is that I prefer a generic data model rather than sacrificing for
hypothetical performance and end up with data model like competitors with
thousands of entities (OFBiz is currently still around 800+)
Jacques
