Re: Separation database for inventory module
Paul, Thank you for your reply and more insights. I was just trying to tell the group OFBiz capabilities that how quickly entities can be separated among databases if required (not to everyone but to those who are newer). And yes in that case CRUD would be slower and only gains is in reads. If we talk about FKs, I did this in past and in case of mysql it maintain the FKs the referential integrity among different db. I do agree with you on the fact that, this is not good idea to have more database, instead OFBiz supports many ways to retrieve the data way faster rather separating the database. So rather that using the separate database, considering the flat information storage would be better idea IMO for faster read. Best Regards, Rishi Solanki Sr Manager, Enterprise Software Development HotWax Systems Pvt. Ltd. Direct: +91-9893287847 http://www.hotwaxsystems.com www.hotwax.co On Sun, Mar 25, 2018 at 7:12 AM, Paul Foxworthy wrote: > On 25 March 2018 at 01:58, Rishi Solanki wrote: > > > > Register new group in entityengine.xml with new name and data resource; > > > > > datasource-name="yourDataResourceName"/> > > > > Add new data resource entry in the entityengine.xml like we have many. In > > your case entityengine will contains two entry as localmysql and > > localmysql2 (or any name you prefer). > > Now register all the entities with "your.group.name" in > entity-group.xml. > > > > Refer > datasource-name="localderbytenant"/> and related entries for more > details. > > > > Thanks Rishi. > > If you do define a new group, does that mean: > > - any transaction that modifies entities in two different groups will be > slower as the transaction must be a distributed transaction with two-phase > commit? To put it another way, with good design decisions, entity groups > may well give you faster reads, but writes very likely won't be? > - Foreign key constraints and thus guaranteed referential integrity might > not be possible between groups because not all DBMSes support FKs that > refer to another database? > > Thanks > > Paul Foxworthy > > -- > Coherent Software Australia Pty Ltd > PO Box 2773 > Cheltenham Vic 3192 > Australia > > Phone: +61 3 9585 6788 > Web: http://www.coherentsoftware.com.au/ > Email: i...@coherentsoftware.com.au >
Fwd: [jira] [Commented] (OFBIZ-6882) Extend the PostalAddress entity with additional elements
Similar to the discussion around design review for Tomcat SSO, here is another example below, admittedly it is 2 years old now but I'm only just seeing it because I'm now using a newer version for work. IMO it's absolutely critical that any non-minor framework or data model changes are discussed in the dev mailing list. It's also absolutely critical that issues raised in review are discussed rather than ignored, nothing should ever be committed when the only reviews are doubtful ones. Regards Scott -- Forwarded message -- From: Scott Gray (JIRA) Date: 26 March 2018 at 02:20 Subject: [jira] [Commented] (OFBIZ-6882) Extend the PostalAddress entity with additional elements To: notificati...@ofbiz.apache.org [ https://issues.apache.org/jira/browse/OFBIZ-6882?page= com.atlassian.jira.plugin.system.issuetabpanels:comment- tabpanel&focusedCommentId=16413283#comment-16413283 ] Scott Gray commented on OFBIZ-6882: --- I'm surprised you went with houseNumber [~jacques.le.roux] What if the address is for an office or a warehouse? Even with review and doubts from others on some of these fields you still went ahead without question or even engaging in the discussion. The houseNumber name is poorly chosen, and Pierre provided no justification for the municipalityGeoId field. This wasn't good committer behavior. > Extend the PostalAddress entity with additional elements > > > Key: OFBIZ-6882 > URL: https://issues.apache.org/jira/browse/OFBIZ-6882 > Project: OFBiz > Issue Type: Improvement > Components: party >Affects Versions: Trunk >Reporter: Pierre Smits >Assignee: Pierre Smits >Priority: Major > Labels: 3rdParty, Shipment, integration > Fix For: 16.11.01 > > Attachments: OFBIZ-6882-party-PostalAddress.patch > > > Various modern day 3rd party delivery solutions (e.g. PostNL in The Netherlands) require that elements are delivered separately, so that addresses can be checked more easily. > Current definition of the PostalAddress doesn't have separation of: > * street name > * house number > * house number addition or extension -- This message was sent by Atlassian JIRA (v7.6.3#76005)
RE: Welcome Paul Foxworthy as a new PMC member
Welcome aboard Paul !! Thanks, Swapnil -Original Message- From: Jacopo Cappellato Sent: Wednesday, March 21, 2018 2:12 PM To: dev@ofbiz.apache.org Subject: Welcome Paul Foxworthy as a new PMC member The OFBiz PMC has invited Paul Foxworthy to become a new member of the committee and we are glad to announce that Paul has accepted the nomination. Welcome on board Paul! Jacopo Cappellato (on behalf of the OFBiz PMC)
Re: svn commit: r1827439 - /ofbiz/ofbiz-framework/trunk/framework/common/servicedef/services.xml
Hi Paul, I agree, that's what I tried to express in my comments on https://issues.apache.org/jira/browse/OFBIZ-10047: "7. Someone should check this solution from an architectural view. I appreciate the efforts but I am also in doubt if we should put this feature into the new release. It's very fresh, deals with a very central functionality and should be field tested more." I really do think that we should have another process when we introduce this kind of new functionality, make use of new third party API etc.. You and Scott made valuable points in this discussion and if we would have had some kind of voting for this, they might be brought up earlier. The Jira discussions just slip through if there is no discussion on the dev list. Thanks, Michael Am 25.03.18 um 03:02 schrieb Paul Foxworthy: Hi all, The servlet4preview package in Tomcat 8.5 "provides early access to some of the features of Servlet 4.0" ( https://tomcat.apache.org/tomcat-8.5-doc/api/org/apache/catalina/servlet4preview/package-summary.html ). Does use of this package make OFBiz dependent on a preview version, and if so is that a good idea? Should features that use some preview (like support for Tomcat SSO, it appears) be contained in a branch or plugin until the API has been stabilised? Tomcat 9 was released in January, with support for Servlet 4.0. If we now say OFBiz requires Servlet 4.0 and move to Tomcat 9, could we then use the standard HttpServletRequest? Thanks Paul Foxworthy On 25 March 2018 at 04:49, Scott Gray wrote: So to summarize your long email ;-) "The service engine has a limitation in that it only checks the interfaces directly implemented by the object being tested. Tomcat's RequestFacade doesn't directly implement javax.servlet.http.HttpServletRequest so it fails to pass the type validation." On the surface your suggested fix looks fine to me, my only concern being that we may need to do some performance testing. For every service that specifies an interface we'll now be checking the full type hierarchy which I imagine will be more expensive but I'm not sure how expensive. I'm also not even sure if our custom ObjectType methods for checking this type of thing are necessary any more with so many new java versions since it was decided these were needed for performance reasons. Regards Scott On 24 March 2018 at 10:59, Jacques Le Roux wrote: Le 23/03/2018 à 17:09, Scott Gray a écrit : I don't need to try anything, I *know* that the service engine is supposed to accept a concrete class of an interface if the interface is specified as the attribute type. Either the service engine is broken by not accepting concrete implementations, or the bug report is incorrect. Neither, it's "unfortunate", and a bit complicated. Tomcat servlet4preview was introduced with Tomcat 8.5 https://tomcat.apache.org/tomcat-8.5-doc/api/org/apache/cata lina/servlet4preview/package-summary.html Before James introduced Tomcat SSO, we had only one service passing a javax.servlet.http.HttpServletRequest to a service: payPalCheckoutUpdate. AFAIK, we have actually always passed a org.apache.catalina.connector. RequestFacade to services when asking for javax.servlet.http.HttpServletRequest in services definition. Since Tomcat 8.5 RequestFacade implements javax.servlet.http. HttpServletRequest indirectly through org.apache.catalina.servlet4pr eview.http.HttpServletRequest https://tomcat.apache.org/tomcat-8.5-doc/api/org/apache/cata lina/connector/RequestFacade.html Since we have no tests on the payPalCheckoutUpdate service we did not spot that Tomcat servlet4preview was introduced with Tomcat 8.5 The classes check is done by the deeper interfaceOf() method of the ObjectType class using Class.getInterfaces() https://docs.oracle.com/javase/8/docs/api/java/lang/Class. html#getInterfaces-- Class.getInterfaces() does not recurse and stops at one level up. So in case of RequestFacade it returns only servlet4preview.http. HttpServletRequest and not javax.servlet.http.HttpServletRequest So when interfaceOf() compares the Classes it fails. What happened with my introduction of the HttpServletRequestWrapper in ContextFilter is it hid the RequestFacade because HttpServletRequestWrapper implements javax.servlet.http.HttpServletRequest https://docs.oracle.com/javaee/7/api/javax/servlet/http/ HttpServletRequest.html So when James introduced Tomcat SSO and optionally passed a javax.servlet.http.HttpServletRequest to the userLogin service it did not break. But when I removed HttpServletRequestWrapper from ContextFilter it popped up Summary: it's unfortunate because we have no tests on the payPalCheckoutUpdate service. Because I temporarily introduced HttpServletRequestWrapper James was able to pass a javax.servlet.http.HttpServletRequest, like in payPalCheckoutUpdate. When I reverted (removed HttpServletRequestWrapper from ContextFilter) I discovered that we had a problem with Tomcat 8.5. I propose this f
