Re: Updates to EntityQuery

Hmmm usually my first gut reaction would be "keep things consistent", however Scott made a good argument for supporting non-common DB features. So my suggestion would be to use something like the widget's tag (or equivalent in code) for any features not supported in all DBMSs. By labeling it as

Re: Updates to EntityQuery

I think it's better to have for-update available for use for the majority of use-cases than it is to exclude it altogether. I'd rather lose the databases that don't support it than constrain the ones that do and are used most by pretty much everyone. It would be nice to hear from anyone using a

Re: Updates to EntityQuery

Hi Gareth, FOR UPDATE is standard SQL, but even so SQLite for one doesn't support it: http://sqlite.1065341.n5.nabble.com/SELECT-FOR-UPDATE-td89630.html https://sqlite.org/lang_select.html FOR UPDATE only makes sense for relational databases. Adding assumptions it's available would make it

Re: Move buildbot messages out of DEV mailing lists

Le 25/10/2017 à 18:11, James Yong a écrit : Hi all, I believe most people has little interest with the historical Buildbot messages while browsing through the topics in the DEV mailing list. Would the COMMITS mailing list be better location for Buildbot messages? This would be a question for

Re: Updates to EntityQuery

Ok I will create a Jira with patch for review. Sent from my Samsung Galaxy smartphone. Gareth Carter Software Development Analyst Stannah Management Services Ltd IT Department Ext: 7036 DDI: 01264 364311 [http://logos.stannah.co.uk/stan150.jpg]

Re: Move buildbot messages out of DEV mailing lists

Hi all, I believe most people has little interest with the historical Buildbot messages while browsing through the topics in the DEV mailing list. Would the COMMITS mailing list be better location for Buildbot messages? Regards, James Yong On 2017-10-24 18:57, Taher Alkhateeb

Re: RE: RE: RE: Quantity missing for inventory transfer records

Hi all, Having suggested possible entity changes to both approaches (with or without Order entity), I prefer not to make use of Order entity for inventory transfer. Order entity is currently shared by Sales Order and Purchase Order. Using Order for transfer may make it harder to expand

Re: Updates to EntityQuery

Looking good to me also. Let me know if I can be of any help. Thanks & Regards -- Deepak Nigam On Wed, Oct 25, 2017 at 6:26 PM, Yash Sharma wrote: > I am all up for it, please let me know if I could help. > > Thanks & Regards, > -- > *Pradhan Yash Sharma* >

Re: Updates to EntityQuery

I am all up for it, please let me know if I could help. Thanks & Regards, -- *Pradhan Yash Sharma* *HotWax Systems* | www.hotwaxsystems.com On Wed, Oct 25, 2017 at 6:23 PM, Yash Sharma wrote: > Yes, Usage of the stream will surely enhance performance to a certain

Re: Updates to EntityQuery

Yes, Usage of the stream will surely enhance performance to a certain extent and removes ceremony from the code base. I think Parallel streams will add enhancements in many folds as we are using a multicore processor (I have not tested yet), but the Functional approach seems promising. Thanks &

Re: svn commit: r1719660 - in /ofbiz/trunk/framework/webapp: config/requestHandler.properties dtd/site-conf.xsd src/org/ofbiz/webapp/control/ConfigXMLReader.java src/org/ofbiz/webapp/control/RequestHa

Hi Michael, Just saw this message, the Jira and your patch, +1 for the whole Thanks Jacques Le 24/10/2017 à 20:04, Michael Brohl a écrit : Hi Jacques, how can I configure a view so that no x-frame-options header is set? While it is great to have these security options and also have a

RE: Updates to EntityQuery

forUpdate We patched EntityFindOptions with a new field "forUpdate" with shorthand methods in EntityQuery to enable. We then made a change to GenericDAO.selectListIteratorByCondition to add "FOR UPDATE" on the end of the SQL select statement - this allows for DB row locks (we use postgres and