+1 for both the points, first introduce the feature with design proposal shared by Ratnesh. And in a separate discussion/effort we can discuss and finalize the generic data model approach. Even this thread is also good start for discussing the generic data model proposal.
Rishi Solanki Sr Manager, Enterprise Software Development HotWax Systems Pvt. Ltd. Direct: +91-9893287847 http://www.hotwaxsystems.com www.hotwax.co On Sun, Sep 24, 2017 at 2:05 AM, Jacques Le Roux < jacques.le.r...@les7arts.com> wrote: > 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 < >> jacques.le.r...@les7arts.com> 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 >>> >>> >
