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 harder to use a NoSQL database in future.

In the case of SQLite, in effect it's got serialized isolation anyway, so
the FOR UPDATE is not strictly necessary.

I suggest OFBiz shouldn't have a method that generates syntactically
incorrect SQL for any database we want to support, and we claim to support
several. Where there are variations between SQL dialects, we have
attributes in the data source, such as "join-style".

So think our choices are:

1. Add an attribute to say "SELECT ... FOR UPDATE" is supported by a data
source. OFBiz would only add the "FOR UPDATE" if it is supported. In the
case of SQLite, I suspect we'd get away without it, but there may be other
databases where the absence of "FOR UPDATE" might bring on unexpected
behaviour.

2. Don't provide a method to expose FOR UPDATE.

Could you achieve the results you want with a higher transaction isolation
level like repeatable read, or with optimistic locking (enable-lock)?

What do you think?

Cheers

Paul Foxworthy


On 26 October 2017 at 07:50, Gareth Carter <gareth.car...@stannah.co.uk>
wrote:

> 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]
>
>
> [http://logos.stannah.co.uk/enviro.jpg]Please consider the environment
> before printing this email.
>
>
> -------- Original message --------
> From: deepak nigam <deepak.nigam1...@gmail.com>
> Date: 25/10/2017 14:06 (GMT+00:00)
> To: dev@ofbiz.apache.org
> Subject: 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 <
> yash.sha...@hotwaxsystems.com>
> wrote:
>
> > I am all up for it, please let me know if I could help.
> >
> > Thanks & Regards,
> > --
> > *Pradhan Yash Sharma*
> > *HotWax Systems* | www.hotwaxsystems.com<http://www.hotwaxsystems.com>
> >
> > On Wed, Oct 25, 2017 at 6:23 PM, Yash Sharma <
> > yash.sha...@hotwaxsystems.com>
> > wrote:
> >
> > > 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 & Regards,
> > > --
> > > *Pradhan Yash Sharma*
> > > *HotWax Systems* | www.hotwaxsystems.com<http://www.hotwaxsystems.com>
> > >
> > > On Wed, Oct 25, 2017 at 5:59 PM, Gareth Carter <
> > > gareth.car...@stannah.co.uk> wrote:
> > >
> > >> 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 works but have not tested other databases). I believe there may
> have
> > >> been a discussion about this before
> > >>
> > >>
> > >> forEach on EntityQuery
> > >>
> > >> Use Consumer in java and groovy to iterate over a query. This can
> reduce
> > >> memory consumption (replacement for queryList()) and boiler plate code
> > (eg
> > >> queryIterator(), while loop and close)
> > >>
> > >> Example:
> > >>
> > >> EntityQuery.use(delegator).from("Foobar")
> > >> .forEach(item ->
> > >>     Debug.logInfo(item.toString(), module);
> > >> );
> > >>
> > >> A further update could be to provide stream capabilities
> > >>
> > >> Hope this helps, I can provide a patch aswell
> > >>
> > >> Gareth Carter
> > >> Software Development Analyst
> > >> Stannah Management Services Ltd
> > >> IT Department
> > >> Ext:
> > >> 7036
> > >> DDI:
> > >> 01264 364311
> > >>
> > >>
> > >> Please consider the environment before printing this email.
> > >>
> > >> -----Original Message-----
> > >> From: Arun Patidar [mailto:arun.pati...@hotwaxsystems.com]
> > >> Sent: 25 October 2017 5:49 AM
> > >> To: dev@ofbiz.apache.org
> > >> Cc: arunpati...@apache.org
> > >> Subject: Re: Updates to EntityQuery
> > >>
> > >> Hello Gareth,
> > >>
> > >> Please provide some more details or patch to understand  - forUpdate
> and
> > >> forEach method utility.
> > >>
> > >> getFieldMap method looks good to me.
> > >>
> > >>
> > >>
> > >> --
> > >> Thanks & Regards
> > >> ---
> > >> Arun Patidar
> > >> Manager, Enterprise Software Development
> > >>
> > >> HotWax Systems Pvt Ltd.
> > >>
> > >> www.hotwaxsystems.com<http://www.hotwaxsystems.com>
> > >>
> > >>
> > >> On Tue, Oct 24, 2017 at 9:06 PM, Gareth Carter <
> > >> gareth.car...@stannah.co.uk>
> > >> wrote:
> > >>
> > >> > Hi all
> > >> >
> > >> > We have internally patched EntityQuery with some additional
> > >> > functionality and before I create a Jira was going to see what the
> > >> community thinks.
> > >> >
> > >> > New functionality:
> > >> >
> > >> > -       New method getFieldMap which returns a Map object of
> selected
> > >> > fields from GenericValue objects, useful for creating cache map
> > >> > objects for lookup
> > >> >
> > >> > -       Support forUpdate
> > >> >
> > >> > -       forEach method to accept Consumer
> > >> >
> > >> > We have found these useful and believe the project can benefit, let
> me
> > >> > know what you think
> > >> >
> > >> > Regards
> > >> >
> > >> > Gareth Carter
> > >> >
> > >> >
> > >> > Software Development Analyst
> > >> >
> > >> >
> > >> > Stannah Management Services Ltd
> > >> >
> > >> >
> > >> > IT Department
> > >> >
> > >> >
> > >> > Ext:
> > >> >
> > >> >
> > >> > 7036
> > >> >
> > >> >
> > >> > DDI:
> > >> >
> > >> >
> > >> > 01264 364311
> > >> >
> > >> >
> > >> >
> > >> >
> > >> > [http://logos.stannah.co.uk/stan150.jpg]
> > >> >
> > >> >
> > >> > [http://logos.stannah.co.uk/enviro.jpg]Please consider the
> > environment
> > >> > before printing this email.
> > >> >
> > >> >
> > >> >
> > >> > This email is intended only for the above addressee. It may contain
> > >> > privileged information. If you are not the addressee you must not
> > >> > copy, distribute, disclose or use any of the information in it. If
> you
> > >> > have received it in error, please delete it and notify the sender.
> > >> >
> > >> > Stannah Lift Holdings Ltd registered No. 686996, Stannah Management
> > >> > Services Ltd registered No. 2483693, Stannah Lift Services Ltd
> > >> > registered No. 1189799, Stannah Microlifts Ltd registered No.
> 964804,
> > >> > Stannah Lifts Ltd registered No. 1189836, Stannah Stairlifts Ltd
> > >> > registered No. 1401451, Global Upholstery Solutions Ltd registered
> No.
> > >> 02452728.
> > >> >
> > >> > All registered offices at Watt Close, East Portway, Andover,
> > >> > Hampshire,
> > >> > SP10 3SD, England.
> > >> >
> > >> > All Registered in England and Wales.
> > >> >
> > >> > This message has been scanned for malware by Websense.
> > >> > www.websense.com<http://www.websense.com>
> > >> >
> > >>
> > >>
> > >> To report this email as spam, please send the original message,
> complete
> > >> with headers to s...@websense.com
> > >>
> > >
> > >
> >
>



-- 
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

Reply via email to