Adam Heath-2 wrote:
If we can provide a generic solution, this will be a good add-on. Please
share your views.
Is it possible that some jdbc metadata parameter can specify whether
the database supports this?
The patch contains a parameter:
+use-order-by-nulls=true
for this
Hi Divesh,
Would be interested by testing this patch?
Thanks
Jacques
From: Bob Morley rmor...@emforium.com
Bob Morley wrote:
Can you please create a jira issue and load your patch, so that
Committers can have a look and give their views on this.
Ok I have created a patch -
Hi Jacques and Bob,
Sorry to reply late on this. I tested this patch and found that this
feature is only supported if we use the derby, postgres, and oracle
databases. This is not supported for Mysql database.
So what I think is this is not a generic solution. But yes it works as
expected,
Divesh Dutta wrote:
Hi Jacques and Bob,
Sorry to reply late on this. I tested this patch and found that this
feature is only supported if we use the derby, postgres, and oracle
databases. This is not supported for Mysql database.
So what I think is this is not a generic solution. But yes it
Bob Morley wrote:
Can you please create a jira issue and load your patch, so that
Committers can have a look and give their views on this.
Ok I have created a patch -
https://issues.apache.org/jira/browse/OFBIZ-3740. We can continue any
discussion on that patch; but it should be noted
Hello Developers,
I see an strange issue on Release 9.04. But that issue does not exists
on latest OFBiz trunk. Below is brief description of issue:
1) When I use any of the method (like findList or findByAnd) of
DelegatorImpl.java class , and sort it by sequenceNum, For eg in
For that call the sorting is done in the database (not cached), so there's
probably a difference in databases or database configs.
-David
On Apr 23, 2010, at 8:49 AM, Divesh Dutta wrote:
Hello Developers,
I see an strange issue on Release 9.04. But that issue does not exists on
latest
David E Jones wrote:
For that call the sorting is done in the database (not cached), so there's
probably a difference in databases or database configs.
Not entirely accurate. The first match on a condition/entity is
cached, as it is returned from the database. If a later call is only
On Apr 23, 2010, at 10:37 AM, Adam Heath wrote:
David E Jones wrote:
For that call the sorting is done in the database (not cached), so there's
probably a difference in databases or database configs.
Not entirely accurate. The first match on a condition/entity is
cached, as it is
David E Jones wrote:
On Apr 23, 2010, at 10:37 AM, Adam Heath wrote:
David E Jones wrote:
For that call the sorting is done in the database (not cached), so there's
probably a difference in databases or database configs.
Not entirely accurate. The first match on a condition/entity is
There are differences in how the various databases elect to sort nulls
using a standard order by clause. Some databases (Postgres and Oracle
I believe) support a NULLS FIRST or NULLS LAST grammar on the
order by clause to dictate this.
I meant to package this up as a patch, but in our
Hello Robert,
To be more clear, I am using same database and database drivers on both
the instances. By the way I think New element in the entityengine.xml
that indicates if a particular data source supports the nulls-first
grammar will be good idea to add on.
Can you please create a jira
No problemo; I will try to get that patch up in the next 48 hours.
It is very odd that you are seeing different results with the same database /
drivers. My understanding is that the sql standard does not dictate how nulls
are sorted and it seemed a split as to having them first or last based
13 matches
Mail list logo
