On lines 184 and 185 in SQLEncoder.java are the following lines (revision 20608...head on the 2.2.x branch).
capabilities.addType((long) 12345);
capabilities.addType((long) -12345);
These lines caused the arcsde module's SQLEncoderSDE class (which inherits the base-class createFilterCapabilities method) to act incorrectly, as the bitmask for supported filters was set to accept BBOX filters.
Are these lines intentional? Commenting them out fixed my problem, and they don't make a whole lot of sense to me at first glance.
--saul
Saul Farber wrote:
On lines 184 and 185 in SQLEncoder.java are the following lines (revision 20608...head on the 2.2.x branch).
capabilities.addType((long) 12345);
capabilities.addType((long) -12345);
These lines caused the arcsde module's SQLEncoderSDE class (which inherits the base-class createFilterCapabilities method) to act incorrectly, as the bitmask for supported filters was set to accept BBOX filters.
Are these lines intentional? Commenting them out fixed my problem, and they don't make a whole lot of sense to me at first glance.
Gabriel wrote:
Have completely no ide what they mean...
svn blames Cory as the one who added those two lines at revision 20608
Cory could you explain what 12345 and -12345 are for?
These were in the code when I started on it... apparently they are for Filter.ALL/NONE
Cory.
Have completely no ide what they mean...
svn blames Cory as the one who added those two lines at revision 20608
Chory could you explain what 12345 and -12345 are for?
On Thursday 03 August 2006 23:48, Saul Farber wrote:
On lines 184 and 185 in SQLEncoder.java are the following lines
(revision 20608...head on the 2.2.x branch).
capabilities.addType((long) 12345);
capabilities.addType((long) -12345);
These lines caused the arcsde module's SQLEncoderSDE class (which
inherits the base-class createFilterCapabilities method) to act
incorrectly, as the bitmask for supported filters was set to accept BBOX
filters.
Are these lines intentional? Commenting them out fixed my problem, and
they don't make a whole lot of sense to me at first glance.
--saul
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your opinions on IT & business topics through brief surveys -- and earn
cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
--
Gabriel Roldán (groldan@anonymised.com)
Axios Engineering (http://www.axios.es)
Tel. +34 944 41 63 84
Fax. +34 944 41 64 90
btw I guess this means that it would be better that arcsde makes its own
fresh FilterCapabilities instead of inheriting the one from SQLEncoder...
On Thursday 03 August 2006 23:48, Saul Farber wrote:
On lines 184 and 185 in SQLEncoder.java are the following lines
(revision 20608...head on the 2.2.x branch).
capabilities.addType((long) 12345);
capabilities.addType((long) -12345);
These lines caused the arcsde module's SQLEncoderSDE class (which
inherits the base-class createFilterCapabilities method) to act
incorrectly, as the bitmask for supported filters was set to accept BBOX
filters.
Are these lines intentional? Commenting them out fixed my problem, and
they don't make a whole lot of sense to me at first glance.
--saul
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your opinions on IT & business topics through brief surveys -- and earn
cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
--
Gabriel Roldán (groldan@anonymised.com)
Axios Engineering (http://www.axios.es)
Tel. +34 944 41 63 84
Fax. +34 944 41 64 90
They were made to be Filter.ALL and Filter.NONE. They're static
singleton constructs I think off the Filter main class.
They should be really easy to implement, and I'd say you should just implement them, you just have to do a query as if there was no filter, and do a query to return nothing. Check the classes to see which is which, I remember them being slightly weird.
C
Gabriel Roldán wrote:
btw I guess this means that it would be better that arcsde makes its own fresh FilterCapabilities instead of inheriting the one from SQLEncoder...
On Thursday 03 August 2006 23:48, Saul Farber wrote:
On lines 184 and 185 in SQLEncoder.java are the following lines
(revision 20608...head on the 2.2.x branch).
capabilities.addType((long) 12345);
capabilities.addType((long) -12345);
These lines caused the arcsde module's SQLEncoderSDE class (which
inherits the base-class createFilterCapabilities method) to act
incorrectly, as the bitmask for supported filters was set to accept BBOX
filters.
Are these lines intentional? Commenting them out fixed my problem, and
they don't make a whole lot of sense to me at first glance.
--saul
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your opinions on IT & business topics through brief surveys -- and earn
cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
--
Chris Holmes
The Open Planning Project
http://topp.openplans.org
Chris Holmes wrote:
They were made to be Filter.ALL and Filter.NONE. They're static
singleton constructs I think off the Filter main class.
They should be really easy to implement, and I'd say you should just implement them, you just have to do a query as if there was no filter, and do a query to return nothing. Check the classes to see which is which, I remember them being slightly weird.
I've refactored and added FilterType.NONE and FilterType.ALL. There is now only one instance of "12345" and "-12345".
Please see JIRA GEOT-916 and GEOT-848. I haven't made any changes to what each SQLEncoder had defined as its Filter capabilities -- only *how* it is defined (in some cases there was a private filtercapabilities variable defined in the class, and the superclass method was obtaining a different variable -- so some differences may be present. Justin pointed out that Postgis does not support BEYOND, so this has been removed.
...now onto GEOT-917 (merge SQLEncoderPostgis and SQLEncoderPostgisGeos)
Cheers,
Cory.
I have changed the values to be positive integers that can mask properly
in order to fix the FilterCapabilities bug i was having with Beyond.
-Justin
Cory Horner wrote:
Chris Holmes wrote:
They were made to be Filter.ALL and Filter.NONE. They're static
singleton constructs I think off the Filter main class.
They should be really easy to implement, and I'd say you should just
implement them, you just have to do a query as if there was no filter,
and do a query to return nothing. Check the classes to see which is
which, I remember them being slightly weird.
I've refactored and added FilterType.NONE and FilterType.ALL. There is
now only one instance of "12345" and "-12345".
Please see JIRA GEOT-916 and GEOT-848. I haven't made any changes to
what each SQLEncoder had defined as its Filter capabilities -- only
*how* it is defined (in some cases there was a private
filtercapabilities variable defined in the class, and the superclass
method was obtaining a different variable -- so some differences may be
present. Justin pointed out that Postgis does not support BEYOND, so
this has been removed.
...now onto GEOT-917 (merge SQLEncoderPostgis and SQLEncoderPostgisGeos)
Cheers,
Cory.
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
!DSPAM:1004,44da708e113729771116852!
--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com