I didn't check the details, but saving all order object together with all articles looks obviously different functionality comparing to a single field update. Having in mind that this point of execution is really critical place also the fact that we do this anticipating possible crash (a crash during the save?) I think this sql might be justifyable. (Hmm but still it would be better to move it to some oxOrder method).
Regards Tomas Liubinas > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of > Mathias Fiedler > Sent: Tuesday, September 22, 2009 3:52 PM > To: [email protected] > Subject: [oxid-dev-general] *****SPAM 5.1 ***** Re: Question > about SQLand/or oxBase > > Hi, > > I didn't want to "complain" about an bug. I just wanted to > talk in principle about using SQL or oxBase functionality. In > my mind we should avoid SQL as often as possible! As it can > have side effects like the one we saw in oxorder. If > order->save is to slow cause he always updates all > orderarticles, maybe the "save" method should be improved to > just update the changes made in the object. This sounds like > a better solution, then maintaining information twice. Once > in SQL and once in the object. > > > > Am 22.09.2009 um 14:01 schrieb Rimvydas Paskevicius: > > > Hi again, some info about this bug with order status: > > > > You can check this bug at bugtrack > > http://bugs.oxid-esales.com/view.php?id=1300 > > The solution is simple, after updating DB record, oxOrder object > > property "oxtransstatus" is updatad also and if you later will save > > order, new status value will be saved too. > > > > > > > > ----- Original Message ----- From: "Rimvydas Paskevicius" > > <[email protected] > > > > > To: <[email protected]> > > Sent: Tuesday, September 22, 2009 1:41 PM > > Subject: Re: [oxid-dev-general] Question about SQL and/or oxBase > > > > > >> Hi, > >> > >> SQL is used to increase performance. On $this->save() not only > >> oxorder object is saved, also all order articles are saved too. > >> There is already bug entry for this problem and it is fixed now. > >> Wait for next release. > >> > >> > >> > >> ----- Original Message ----- From: "Mathias Fiedler" > >> <[email protected] > >> > > >> To: <[email protected]> > >> Sent: Tuesday, September 22, 2009 11:01 AM > >> Subject: [oxid-dev-general] Question about SQL and/or oxBase > >> > >> > >>> Hello List, > >>> > >>> one general question about usage of SQL or oxBase Objects. > >>> > >>> When you have a look at the " protected function > >>> _setOrderStatus( $sStatus )" in oxOrder a question arises: "Why > >>> direct SQL and not > >>> > >>> $this->oxorder__oxtransstatus->setValue("OK"); > >>> $this->save(); > >>> > >>> Would be much cleaner then using SQL here, or? > >>> > >>> Problem that arises from using sql: in the oxorder object the > >>> oxtransstatus is still "ERROR", so when u save the order object > >>> later (e.g. after "finalizeorder" in a module) the "OK" status is > >>> replaced by "ERROR" again -> Inconsistence > >>> > >>> comments? > >>> > >>> Bye > >>> > >>> Mathias > >>> _______________________________________________ > >>> dev-general mailing list > >>> [email protected] > >>> http://dir.gmane.org/gmane.comp.php.oxid.general > >>> > >> > >> _______________________________________________ > >> dev-general mailing list > >> [email protected] > >> http://dir.gmane.org/gmane.comp.php.oxid.general > > > > _______________________________________________ > > dev-general mailing list > > [email protected] > > http://dir.gmane.org/gmane.comp.php.oxid.general > > _______________________________________________ > dev-general mailing list > [email protected] > http://dir.gmane.org/gmane.comp.php.oxid.general > _______________________________________________ dev-general mailing list [email protected] http://dir.gmane.org/gmane.comp.php.oxid.general
