From trac_fdo at osgeo.org Mon Oct 5 03:31:08 2026 From: trac_fdo at osgeo.org (FDO) Date: Mon, 05 Oct 2026 10:31:08 -0000 Subject: [Fdo-trac] [fdo-trac] #964: Implement GenericRdbms trace (via FDO_TRACE_FILE) for Linux In-Reply-To: <036.37561bf96791cd6834f4f4a4dfbaa794@osgeo.org> References: <036.37561bf96791cd6834f4f4a4dfbaa794@osgeo.org> Message-ID: <051.4c9c338d0a764a0f42cd4913fcfc967a@osgeo.org> #964: Implement GenericRdbms trace (via FDO_TRACE_FILE) for Linux ------------------------------+---------------------- Reporter: jng | Owner: jng Type: enhancement | Status: closed Priority: major | Milestone: Component: GenericRdbms API | Version: Severity: 3 | Resolution: fixed Keywords: | External ID: ------------------------------+---------------------- Changes (by jng): * resolution: => fixed * status: assigned => closed Comment: In [changeset:"8362" 8362]: {{{#!CommitTicketReference repository="" revision="8362" Implement FDO_TRACE_FILE support for Linux. Fixes #964 }}} -- Ticket URL: FDO Feature Data Objects From trac_fdo at osgeo.org Mon Oct 5 04:40:22 2026 From: trac_fdo at osgeo.org (FDO) Date: Mon, 05 Oct 2026 11:40:22 -0000 Subject: [Fdo-trac] [fdo-trac] #1012: PostgreSQL Provider: Re-try using bind variables for geometry value In-Reply-To: <036.6457611b1083cef5fcb5e5a59abc5b2e@osgeo.org> References: <036.6457611b1083cef5fcb5e5a59abc5b2e@osgeo.org> Message-ID: <051.6c9bc87550b36ace8a518fb32751f94c@osgeo.org> #1012: PostgreSQL Provider: Re-try using bind variables for geometry value ---------------------------------+---------------------- Reporter: jng | Owner: jng Type: enhancement | Status: closed Priority: major | Milestone: 4.2.0 Component: PostgreSQL Provider | Version: Severity: 3 | Resolution: fixed Keywords: | External ID: ---------------------------------+---------------------- Changes (by jng): * resolution: => fixed * status: assigned => closed Comment: In [changeset:"8364" 8364]: {{{#!CommitTicketReference repository="" revision="8364" PostgreSQL provider: Re-try using bind variables for geometry values, thus avoiding a pointless WKB->Hex->WKB roundtrip in SQL query generation, allowing us to hand the raw geometry bytes down to libpq directly as a parameter value. Fixes #1012 }}} -- Ticket URL: FDO Feature Data Objects From trac_fdo at osgeo.org Mon Oct 5 06:34:30 2026 From: trac_fdo at osgeo.org (FDO) Date: Mon, 05 Oct 2026 13:34:30 -0000 Subject: [Fdo-trac] [fdo-trac] #1013: Memory leak sweep Message-ID: <036.7601d7effcd9bcfbad02f47275ff2e82@osgeo.org> #1013: Memory leak sweep -----------------------+---------------------- Reporter: jng | Owner: jng Type: task | Status: assigned Priority: major | Milestone: 4.2.0 Component: General | Version: Severity: 3 | Keywords: External ID: | -----------------------+---------------------- Once we've got Linux debug builds to test pass parity with Windows, we should go through all the ASAN reported leaks and plug them all. -- Ticket URL: FDO Feature Data Objects From trac_fdo at osgeo.org Tue Oct 6 04:07:02 2026 From: trac_fdo at osgeo.org (FDO) Date: Tue, 06 Oct 2026 11:07:02 -0000 Subject: [Fdo-trac] [fdo-trac] #936: MySQL test failure: MySqlFdoApplySchemaTest.TestSchema In-Reply-To: <036.03cd68267294a5357ca2df9f228855dc@osgeo.org> References: <036.03cd68267294a5357ca2df9f228855dc@osgeo.org> Message-ID: <051.8a828d8d84f0c0a10b979ba8e0ebacd5@osgeo.org> #936: MySQL test failure: MySqlFdoApplySchemaTest.TestSchema ----------------------------+---------------------- Reporter: jng | Owner: jng Type: defect | Status: closed Priority: major | Milestone: 4.1.0 Component: MySQL Provider | Version: 4.0.0 Severity: 3 | Resolution: fixed Keywords: | External ID: ----------------------------+---------------------- Changes (by jng): * resolution: => fixed * status: new => closed Comment: Determined the best "fix" is to just stand up the relevant MySQL server with case-insensitive collation. -- Ticket URL: FDO Feature Data Objects From trac_fdo at osgeo.org Tue Oct 6 04:14:01 2026 From: trac_fdo at osgeo.org (FDO) Date: Tue, 06 Oct 2026 11:14:01 -0000 Subject: [Fdo-trac] [fdo-trac] #197: acinclude.m4:7: warning: underquoted definition of FDO_HELP_STRING In-Reply-To: <042.aa2904b57e32fef193d99908edb34821@osgeo.org> References: <042.aa2904b57e32fef193d99908edb34821@osgeo.org> Message-ID: <057.2e0f33fc016102bbb886b44f559baf77@osgeo.org> #197: acinclude.m4:7: warning: underquoted definition of FDO_HELP_STRING --------------------------+----------------------- Reporter: warmerdam | Owner: (none) Type: defect | Status: closed Priority: trivial | Milestone: 3.4.0 Component: Build System | Version: 3.2.0 Severity: 4 | Resolution: invalid Keywords: | External ID: --------------------------+----------------------- Changes (by jng): * resolution: => invalid * status: new => closed Old description: > {{{ > warmerda at gdal64[52]% ./build_thirdparty.sh > Configuring FDO Makefiles > acinclude.m4:7: warning: underquoted definition of FDO_HELP_STRING > acinclude.m4:7: run info '(automake)Extending aclocal' > acinclude.m4:7: or see http://sources.redhat.com/automake/automake.html > #Extending-aclocal > }}} > > This occurs on my ubuntu 7.10 system running autoconf 2.61. > > I'll work on a quoting fix. The problem is not serious as far as I know. > I think it just produces the somewhat alarming warning at the beginning > of the build but otherwise works fine. New description: {{{ warmerda at gdal64[52]% ./build_thirdparty.sh Configuring FDO Makefiles acinclude.m4:7: warning: underquoted definition of FDO_HELP_STRING acinclude.m4:7: run info '(automake)Extending aclocal' acinclude.m4:7: or see http://sources.redhat.com/automake/automake.html #Extending-aclocal }}} This occurs on my ubuntu 7.10 system running autoconf 2.61. I'll work on a quoting fix. The problem is not serious as far as I know. I think it just produces the somewhat alarming warning at the beginning of the build but otherwise works fine. -- Comment: No longer valid as autotools has long been replaced with CMake -- Ticket URL: FDO Feature Data Objects From trac_fdo at osgeo.org Tue Oct 6 04:20:38 2026 From: trac_fdo at osgeo.org (FDO) Date: Tue, 06 Oct 2026 11:20:38 -0000 Subject: [Fdo-trac] [fdo-trac] #547: Support for OGC Web Processing Service (WPS) In-Reply-To: <041.dea5da8655379cc9d5bb1a032d05372e@osgeo.org> References: <041.dea5da8655379cc9d5bb1a032d05372e@osgeo.org> Message-ID: <056.cb2e2d5cde1259ff2476a4d014787495@osgeo.org> #547: Support for OGC Web Processing Service (WPS) -------------------------+------------------------- Reporter: ssddgreg | Owner: gregboone Type: enhancement | Status: closed Priority: critical | Milestone: 3.6.0 Component: FDO API | Version: 3.4.0 Severity: 3 | Resolution: duplicate Keywords: OGC, WPS | External ID: -------------------------+------------------------- Changes (by jng): * resolution: => duplicate * status: new => closed Comment: This is a MapGuide-level enhancement request. Relocated to: https://trac.osgeo.org/mapguide/ticket/2892 -- Ticket URL: FDO Feature Data Objects From trac_fdo at osgeo.org Tue Oct 6 04:22:18 2026 From: trac_fdo at osgeo.org (FDO) Date: Tue, 06 Oct 2026 11:22:18 -0000 Subject: [Fdo-trac] [fdo-trac] #193: UnitTests on MySQL 5.1.22-rc-community - Run: 228 Failures: 43 Errors: 20 In-Reply-To: <038.12af125d61a8231fb662a0ae1d760ad9@osgeo.org> References: <038.12af125d61a8231fb662a0ae1d760ad9@osgeo.org> Message-ID: <053.848c808f629b0eea3c19d4370e3ba6c1@osgeo.org> #193: UnitTests on MySQL 5.1.22-rc-community - Run: 228 Failures: 43 Errors: 20 ----------------------------+------------------------- Reporter: based | Owner: gregboone Type: defect | Status: closed Priority: major | Milestone: 3.4.0 Component: MySQL Provider | Version: 3.3.0 Severity: 3 | Resolution: wontfix Keywords: | External ID: ----------------------------+------------------------- Changes (by jng): * resolution: => wontfix * status: new => closed Comment: MySQL 5.6 is now our minimum baseline -- Ticket URL: FDO Feature Data Objects From trac_fdo at osgeo.org Tue Oct 6 07:56:17 2026 From: trac_fdo at osgeo.org (FDO) Date: Tue, 06 Oct 2026 14:56:17 -0000 Subject: [Fdo-trac] [fdo-trac] #1007: Replace usage of tempnam with mkstemp in FdoCommonFile In-Reply-To: <036.f938aca3c3221259af1e7a0a21cb7ce2@osgeo.org> References: <036.f938aca3c3221259af1e7a0a21cb7ce2@osgeo.org> Message-ID: <051.42b70b7685d664fcc5262ba770e29e46@osgeo.org> #1007: Replace usage of tempnam with mkstemp in FdoCommonFile ---------------------+---------------------- Reporter: jng | Owner: jng Type: task | Status: closed Priority: major | Milestone: 4.2.0 Component: FDO API | Version: Severity: 3 | Resolution: fixed Keywords: | External ID: ---------------------+---------------------- Changes (by jng): * resolution: => fixed * status: assigned => closed Comment: In [changeset:"8372" 8372]: {{{#!CommitTicketReference repository="" revision="8372" FdoCommonFile::GetTempFile(): Generate the temporary name with mkstemp() instead of tempnam() tempnam() has been deprecated for decades because the name it returns can be stolen between the call and the caller's own open() - GCC warns about it on every link of every provider and the suite that actually uses the function ("the use of `tempnam' is dangerous, better use `mkstemp'"). The POSIX branch of GetTempFile() now builds an "/idfXXXXXX" template and hands it to mkstemp(), which creates the file with owner-only permissions and returns a name nothing else can have taken. The file mkstemp() creates is closed and unlinked before returning, so the name still comes back in the same "unique, but not created yet" state that the Windows branch already returns: that branch calls GetTempFileName() and then deletes what it made, and the callers (ShpFileSet, ShpSpatialIndex and ShapeIndex) open - and so create - the name themselves, some of them with IDF_CREATE_NEW, which fails if the file is already there. Leaving the file in place would have been a contract change, so it is removed as well as created; the alternative of not creating it at all is what tempnam() did and what the warning is about. Behaviour is otherwise unchanged: the given directory is used when there is one (a missing or unwritable directory now fails here rather than at the caller's open, which is what the return value documents), an empty path falls back to TMPDIR and then P_tmpdir the way tempnam(NULL, ...) did, the name keeps its "idf" prefix and is still allocated with new[] for the caller to delete[], and a failure still returns false with errno set. Verified against the built library: the returned name is in the requested directory, does not exist, is unique across calls, can be created with O_CREAT|O_EXCL and with FdoCommonFile::OpenFile(IDF_OPEN_UPDATE|IDF_CREATE_NEW), and nothing is left behind in the temporary directory. The SHP suite - the only suite that reaches GetTempFile, through the spatial index and fileset temporary-file fallbacks - is still green (OK (138)) with no leaks, and the FDO Core suite is unchanged (OK (123)). Fixes #1007 }}} -- Ticket URL: FDO Feature Data Objects From trac_fdo at osgeo.org Tue Oct 6 08:56:02 2026 From: trac_fdo at osgeo.org (FDO) Date: Tue, 06 Oct 2026 15:56:02 -0000 Subject: [Fdo-trac] [fdo-trac] #891: Sqlite Provider: Access Violation exception in method BuildMetaData() In-Reply-To: <039.f8263fcb808634f4dd8b12cb284d14a3@osgeo.org> References: <039.f8263fcb808634f4dd8b12cb284d14a3@osgeo.org> Message-ID: <054.3bcb1975318294bcb38aac3f005586ab@osgeo.org> #891: Sqlite Provider: Access Violation exception in method BuildMetaData() -----------------------------+---------------------------- Reporter: zhanga | Owner: traianstanev Type: defect | Status: closed Priority: major | Milestone: 3.9.0 Component: SQLite Provider | Version: 3.9.0 Severity: 3 | Resolution: fixed Keywords: | External ID: -----------------------------+---------------------------- Changes (by jng): * resolution: => fixed * status: new => closed Comment: In [changeset:"8373" 8373]: {{{#!CommitTicketReference repository="" revision="8373" SQLite: Re-apply the metadata locking of r7133 in a form that also works on Linux r7133 ("#891 Sqlite Provider: Access Violation exception in method BuildMetaData()") fixed a Windows access violation caused by two threads building the provider's metadata cache at the same time by serializing SltMetadata::BuildMetadataInfo() in SltConnection::DescribeSchema() with m_csMd. It was reverted in r7150 because it made the Linux unit tests hang. The locking itself was fine; the platform underneath it was not. STL_CRITICAL_SECTION in SltProvider.h is the Win32 CRITICAL_SECTION on Windows, which is recursive - the owning thread may enter it again - but a plain pthread_mutex_init(m, NULL) mutex on POSIX, which is not. The metadata build nests: BuildMetadataInfo() -> SltMetadata::ProcessViewProperties() -> SltConnection::GetMetadata(), which takes m_csMd again for the geometry table of a view. On Windows that inner acquisition just bumps the recursion count; on Linux it waited forever on a lock only the waiting thread could release, which is exactly the stack in ticket 895 (SelectTest::TestViewSelects -> SltDescribeSchema::Execute -> SltMetadata::BuildMetadataInfo -> SltMetadata::ProcessViewProperties -> SltConnection::GetMetadata -> CriticalSectionHolder, blocked in pthread_mutex_lock). The POSIX branch of the abstraction now initializes its mutexes as PTHREAD_MUTEX_RECURSIVE via pthread_mutexattr_settype(), so the shim has the semantics the rest of the provider already assumes - CriticalSectionHolder and the query-cache code were written for a lock that can be re-entered - and on top of that r7133's two m_csMd acquisitions in DescribeSchema() are restored: around BuildMetadataInfo() in the requested-class-names branch, and before BuildMetadataInfo() in the full-schema path rather than after it. This also removes a latent deadlock that is in the 4.2 tree today, independent of r7133: GetMetadata() already holds m_csMd while calling BuildMetadataInfo(), so any view whose geometry table is itself a view was one m_bUseFdoMetadata away from the same hang. The three ForceLeaveCriticalSection() calls in the query-cache paths are left alone. They were added for the same non-recursive-mutex reason, so they are now redundant for correctness, but they also release the lock while sqlite3_reset()/sqlite3_prepare_v2() run, and changing that lock hold time is a separate decision. Verified on the baseline distro (ubuntu22, Debug): with only the DescribeSchema() locking applied the suite hangs - single-threaded process, no CPU burned, blocked in futex_do_wait - and with the recursive mutex as well it is green again: SelectTest alone passes (OK (33)) and the full suite passes (OK (89)) with no leaks, including the FdoMultiThreadTest query and insert tests that this locking is meant to protect. Fixes #891 Fixes #895 }}} -- Ticket URL: FDO Feature Data Objects From trac_fdo at osgeo.org Tue Oct 6 08:56:02 2026 From: trac_fdo at osgeo.org (FDO) Date: Tue, 06 Oct 2026 15:56:02 -0000 Subject: [Fdo-trac] [fdo-trac] #895: SQLite unit test deadlock In-Reply-To: <036.228137321b7bba8d9ce42c9ceb531cb8@osgeo.org> References: <036.228137321b7bba8d9ce42c9ceb531cb8@osgeo.org> Message-ID: <051.6cb92a36c1849428341452e978ab9b98@osgeo.org> #895: SQLite unit test deadlock -----------------------------+---------------------------- Reporter: jng | Owner: traianstanev Type: defect | Status: closed Priority: critical | Milestone: Component: SQLite Provider | Version: Severity: 1 | Resolution: fixed Keywords: | External ID: -----------------------------+---------------------------- Changes (by jng): * resolution: => fixed * status: new => closed Comment: In [changeset:"8373" 8373]: {{{#!CommitTicketReference repository="" revision="8373" SQLite: Re-apply the metadata locking of r7133 in a form that also works on Linux r7133 ("#891 Sqlite Provider: Access Violation exception in method BuildMetaData()") fixed a Windows access violation caused by two threads building the provider's metadata cache at the same time by serializing SltMetadata::BuildMetadataInfo() in SltConnection::DescribeSchema() with m_csMd. It was reverted in r7150 because it made the Linux unit tests hang. The locking itself was fine; the platform underneath it was not. STL_CRITICAL_SECTION in SltProvider.h is the Win32 CRITICAL_SECTION on Windows, which is recursive - the owning thread may enter it again - but a plain pthread_mutex_init(m, NULL) mutex on POSIX, which is not. The metadata build nests: BuildMetadataInfo() -> SltMetadata::ProcessViewProperties() -> SltConnection::GetMetadata(), which takes m_csMd again for the geometry table of a view. On Windows that inner acquisition just bumps the recursion count; on Linux it waited forever on a lock only the waiting thread could release, which is exactly the stack in ticket 895 (SelectTest::TestViewSelects -> SltDescribeSchema::Execute -> SltMetadata::BuildMetadataInfo -> SltMetadata::ProcessViewProperties -> SltConnection::GetMetadata -> CriticalSectionHolder, blocked in pthread_mutex_lock). The POSIX branch of the abstraction now initializes its mutexes as PTHREAD_MUTEX_RECURSIVE via pthread_mutexattr_settype(), so the shim has the semantics the rest of the provider already assumes - CriticalSectionHolder and the query-cache code were written for a lock that can be re-entered - and on top of that r7133's two m_csMd acquisitions in DescribeSchema() are restored: around BuildMetadataInfo() in the requested-class-names branch, and before BuildMetadataInfo() in the full-schema path rather than after it. This also removes a latent deadlock that is in the 4.2 tree today, independent of r7133: GetMetadata() already holds m_csMd while calling BuildMetadataInfo(), so any view whose geometry table is itself a view was one m_bUseFdoMetadata away from the same hang. The three ForceLeaveCriticalSection() calls in the query-cache paths are left alone. They were added for the same non-recursive-mutex reason, so they are now redundant for correctness, but they also release the lock while sqlite3_reset()/sqlite3_prepare_v2() run, and changing that lock hold time is a separate decision. Verified on the baseline distro (ubuntu22, Debug): with only the DescribeSchema() locking applied the suite hangs - single-threaded process, no CPU burned, blocked in futex_do_wait - and with the recursive mutex as well it is green again: SelectTest alone passes (OK (33)) and the full suite passes (OK (89)) with no leaks, including the FdoMultiThreadTest query and insert tests that this locking is meant to protect. Fixes #891 Fixes #895 }}} -- Ticket URL: FDO Feature Data Objects From trac_fdo at osgeo.org Tue Oct 6 08:59:40 2026 From: trac_fdo at osgeo.org (FDO) Date: Tue, 06 Oct 2026 15:59:40 -0000 Subject: [Fdo-trac] [fdo-trac] #1005: King Oracle Provider memory leak sweep In-Reply-To: <036.a8c20bf72b946d720eb91821b23a1a2d@osgeo.org> References: <036.a8c20bf72b946d720eb91821b23a1a2d@osgeo.org> Message-ID: <051.9aab6ba2fa0b5b4eae025923af2269a7@osgeo.org> #1005: King Oracle Provider memory leak sweep ---------------------------------+------------------------- Reporter: jng | Owner: jng Type: defect | Status: closed Priority: major | Milestone: 4.2.0 Component: KingOracle Provider | Version: 4.1.0 Severity: 3 | Resolution: duplicate Keywords: | External ID: ---------------------------------+------------------------- Changes (by jng): * resolution: => duplicate * status: assigned => closed Comment: Lumped into #1013 -- Ticket URL: FDO Feature Data Objects From trac_fdo at osgeo.org Wed Oct 7 02:52:52 2026 From: trac_fdo at osgeo.org (FDO) Date: Wed, 07 Oct 2026 09:52:52 -0000 Subject: [Fdo-trac] [fdo-trac] #332: SQLite: Please provide "Default" Spatial Context when no CS present In-Reply-To: <039.239763f84e1cb806d8781f05add2fbff@osgeo.org> References: <039.239763f84e1cb806d8781f05add2fbff@osgeo.org> Message-ID: <054.996d3ae969c8126495562feb0117def2@osgeo.org> #332: SQLite: Please provide "Default" Spatial Context when no CS present -----------------------------+---------------------------- Reporter: jbirch | Owner: traianstanev Type: enhancement | Status: closed Priority: minor | Milestone: Component: SQLite Provider | Version: 3.3.1 Severity: 3 | Resolution: fixed Keywords: | External ID: -----------------------------+---------------------------- Changes (by jng): * resolution: => fixed * status: new => closed Comment: In [changeset:"8375" 8375]: {{{#!CommitTicketReference repository="" revision="8375" SQLite: Support "Default" spatial context when SQLite data store has no coordinate systems registered. Fixes #332 }}} -- Ticket URL: FDO Feature Data Objects From trac_fdo at osgeo.org Wed Oct 7 03:24:08 2026 From: trac_fdo at osgeo.org (FDO) Date: Wed, 07 Oct 2026 10:24:08 -0000 Subject: [Fdo-trac] [fdo-trac] #928: QueryFeatures Request fails when there are CurvePolygons in PostGIS table In-Reply-To: <041.fcb99d403b598314e328be95ecf113f3@osgeo.org> References: <041.fcb99d403b598314e328be95ecf113f3@osgeo.org> Message-ID: <056.49bc827e8724ba77a4354e13ae8ba3a9@osgeo.org> #928: QueryFeatures Request fails when there are CurvePolygons in PostGIS table -------------------------------------------------+------------------------- Reporter: andymorf | Owner: | badreddinekaroui Type: defect | Status: closed Priority: major | Milestone: 4.1.0 Component: PostgreSQL Provider | Version: 4.0.0 Severity: 3 | Resolution: fixed Keywords: PostGIS, CurvePolygon, | External ID: CompoundCurve | -------------------------------------------------+------------------------- Changes (by jng): * resolution: => fixed * status: new => closed Comment: Fixed r8374 -- Ticket URL: FDO Feature Data Objects From trac_fdo at osgeo.org Wed Oct 7 03:50:53 2026 From: trac_fdo at osgeo.org (FDO) Date: Wed, 07 Oct 2026 10:50:53 -0000 Subject: [Fdo-trac] [fdo-trac] #687: GDAL Provider memory leak In-Reply-To: <040.d182593960a47eb16d9329c768b199ca@osgeo.org> References: <040.d182593960a47eb16d9329c768b199ca@osgeo.org> Message-ID: <055.4595f3a7bc10994896d1e06899668bb1@osgeo.org> #687: GDAL Provider memory leak ---------------------------+------------------------- Reporter: vrifino | Owner: warmerdam Type: defect | Status: closed Priority: critical | Milestone: 3.5.0 Component: GDAL Provider | Version: 3.5.0 Severity: 2 | Resolution: duplicate Keywords: | External ID: ---------------------------+------------------------- Changes (by jng): * resolution: => duplicate * status: reopened => closed Comment: Lumping into #1013 -- Ticket URL: FDO Feature Data Objects From trac_fdo at osgeo.org Wed Oct 7 05:11:44 2026 From: trac_fdo at osgeo.org (FDO) Date: Wed, 07 Oct 2026 12:11:44 -0000 Subject: [Fdo-trac] [fdo-trac] #377: MultiGeometries can't be read from MapInfo .tab file In-Reply-To: <040.ad67dfbe00469cd751cb3f875c2481bc@osgeo.org> References: <040.ad67dfbe00469cd751cb3f875c2481bc@osgeo.org> Message-ID: <055.a01f7beb77dc52ae29af39a61d2581aa@osgeo.org> #377: MultiGeometries can't be read from MapInfo .tab file ---------------------+------------------------- Reporter: paulggp | Owner: gregboone Type: defect | Status: closed Priority: major | Milestone: 4.2.0 Component: FDO API | Version: 3.3.1 Severity: 3 | Resolution: fixed Keywords: | External ID: ---------------------+------------------------- Changes (by jng): * resolution: => fixed * status: new => closed Comment: In [changeset:"8378" 8378]: {{{#!CommitTicketReference repository="" revision="8378" Support MultiGeometries in the OGR provider. Fixes #377 }}} -- Ticket URL: FDO Feature Data Objects From trac_fdo at osgeo.org Wed Oct 7 06:22:57 2026 From: trac_fdo at osgeo.org (FDO) Date: Wed, 07 Oct 2026 13:22:57 -0000 Subject: [Fdo-trac] [fdo-trac] #247: Using an ISelect with an InFilter with an invalid property name yields an AccessViolationException In-Reply-To: <046.8ebbdb3733d97a89899608259f1a5c08@osgeo.org> References: <046.8ebbdb3733d97a89899608259f1a5c08@osgeo.org> Message-ID: <061.fae8cb92fd87bd2057a9a1bc3f27faa0@osgeo.org> #247: Using an ISelect with an InFilter with an invalid property name yields an AccessViolationException ----------------------------+------------------------- Reporter: chrisErickson | Owner: gregboone Type: defect | Status: closed Priority: major | Milestone: 3.4.0 Component: MySQL Provider | Version: 3.2.0 Severity: 4 | Resolution: fixed Keywords: | External ID: ----------------------------+------------------------- Changes (by jng): * resolution: => fixed * status: assigned => closed Comment: In [changeset:"8381" 8381]: {{{#!CommitTicketReference repository="" revision="8381" GenericRdbms: Fix infinite recursion in FdoRdbmsFilterProcessor::AppendObjectProperty The function called itself unconditionally, so any select or filter that references an object property overflowed the stack. The call was introduced by the r4294 ProcessIdentifier refactor; removing it restores the pre-r4294 behaviour (map the object property to its column, or throw the existing FdoFilterException). Added shared FdoSelectTest coverage for a non- existent InCondition property. Fixes #247 (in reality, this was probably fixed earlier but at least we've confirmed it now) }}} -- Ticket URL: FDO Feature Data Objects From trac_fdo at osgeo.org Wed Oct 7 06:49:45 2026 From: trac_fdo at osgeo.org (FDO) Date: Wed, 07 Oct 2026 13:49:45 -0000 Subject: [Fdo-trac] [fdo-trac] #642: Sqlite filtering on number with more that 5 decimal fails In-Reply-To: <039.3bf96a7f5f9500e85b1e1329c322919f@osgeo.org> References: <039.3bf96a7f5f9500e85b1e1329c322919f@osgeo.org> Message-ID: <054.7b5986dfad2316ca0492709281d6608c@osgeo.org> #642: Sqlite filtering on number with more that 5 decimal fails -----------------------------+---------------------------- Reporter: bscott | Owner: traianstanev Type: defect | Status: closed Priority: major | Milestone: 3.5.0 Component: SQLite Provider | Version: 3.5.0 Severity: 3 | Resolution: fixed Keywords: | External ID: -----------------------------+---------------------------- Changes (by jng): * resolution: => fixed * status: assigned => closed Comment: Already fixed in r5500 -- Ticket URL: FDO Feature Data Objects From trac_fdo at osgeo.org Wed Oct 7 07:14:49 2026 From: trac_fdo at osgeo.org (FDO) Date: Wed, 07 Oct 2026 14:14:49 -0000 Subject: [Fdo-trac] [fdo-trac] #644: Sqlite filtering on date returns wrong results In-Reply-To: <039.a9cec5cf8333f9693e30442ea450086f@osgeo.org> References: <039.a9cec5cf8333f9693e30442ea450086f@osgeo.org> Message-ID: <054.b2dde33988e4fc4aebce5e07995bd421@osgeo.org> #644: Sqlite filtering on date returns wrong results -----------------------------+---------------------------- Reporter: bscott | Owner: traianstanev Type: defect | Status: closed Priority: major | Milestone: 3.5.0 Component: SQLite Provider | Version: 3.5.0 Severity: 3 | Resolution: fixed Keywords: | External ID: -----------------------------+---------------------------- Changes (by jng): * resolution: => fixed * status: new => closed Comment: In [changeset:"8383" 8383]: {{{#!CommitTicketReference repository="" revision="8383" Fix SQLite DATE filters on DateTime properties DateToString() now renders a date-only FdoDateTime in the canonical datetime form (YYYY-MM-DDTHH:MM:SS.mmm), so DATE literal filters compare correctly against stored DateTime text. Previously '= DATE' matched no rows and '> DATE' / '<= DATE' matched the wrong rows. Note the behaviour change: a date-only value is now stored and read back as a midnight timestamp (hour 0 rather than -1). InsertTest declares DefaultsTime() to reflect this. Also adds DateTimeFilterTest covering DATE, TIMESTAMP and null filters. Fixes #644 }}} -- Ticket URL: FDO Feature Data Objects From trac_fdo at osgeo.org Wed Oct 7 08:49:02 2026 From: trac_fdo at osgeo.org (FDO) Date: Wed, 07 Oct 2026 15:49:02 -0000 Subject: [Fdo-trac] [fdo-trac] #1001: Where possible, the GDAL provider should try to include the result of CPLGetLastErrorMsg() in its exception message before throwing In-Reply-To: <036.2921711d59173e0c3024957d62b4ff24@osgeo.org> References: <036.2921711d59173e0c3024957d62b4ff24@osgeo.org> Message-ID: <051.2e1e71ef228e008afbec217c0d8c403b@osgeo.org> #1001: Where possible, the GDAL provider should try to include the result of CPLGetLastErrorMsg() in its exception message before throwing ---------------------------+---------------------- Reporter: jng | Owner: jng Type: defect | Status: closed Priority: major | Milestone: 4.2.0 Component: GDAL Provider | Version: 4.1.0 Severity: 3 | Resolution: fixed Keywords: | External ID: ---------------------------+---------------------- Changes (by jng): * resolution: => fixed * status: assigned => closed Comment: In [changeset:"8385" 8385]: {{{#!CommitTicketReference repository="" revision="8385" Include the underlying GDAL error in GDAL provider exceptions The GDAL provider reported failures such as "Fail to get image information." (GRFP_95) without the reason GDAL had already recorded via CPLGetLastErrorMsg(), so an unreadable or unsupported raster produced an undiagnosable error. The OGR provider has surfaced CPL errors through its CHECK_CPL_ERROR macro since r8060; the GDAL provider did so only in the tile read/resample paths, and the GDALOpen in FdoRfpDatasetCache::LockDataset discarded the error outright. The detail is now carried by the message catalogue rather than concatenated in code, so each symbolic id declares for itself whether it is parameterized: the affected messages take a %1$ls, which is the GDAL/OGR error text. Changes: - Providers/GDAL/Src/Message/GRFPMessage.mc: - GRFP_95_CANNOT_GET_IMAGE_INFO is now parameterized: "Fail to get image information. %1$ls". - Added four parameterized messages for the raster read failures that previously threw the raw CPL text with no symbolic id: GRFP_111_CANNOT_READ_RASTER_TILE (GDALDatasetRasterIO failure) GRFP_112_CANNOT_OPEN_RESAMPLED_DATASET GRFP_113_CANNOT_OPEN_TILE_DATASET GRFP_114_CANNOT_CREATE_WARP_OPERATION - Added FdoRfpRasterUtil::GetLastGdalErrorMessage(), which reads CPLGetLastErrorMsg(), converts it to a wide string and calls CPLErrorReset() so that a stale error cannot be attributed to a later, unrelated failure on the same thread - the defect the OGR provider fixed in r8351. - FdoRfpGeoBandRasterImp, FdoRfpStreamReaderByTile and FdoRfpStreamReaderByTileResample now throw the messages above with the GDAL error as %1$ls, replacing the duplicated multibyte_to_wide(CPLGetLastErrorMsg()) blocks. - Declared the .mc as a dependency of every generated message header and catalogue (FDO core, SchemaMgr, and the GDAL/SDF/SHP/WFS/WMS/KingOracle/ GenericRdbms providers). Without it, an incremental build kept the previous catalogue text and silently dropped the %1$ls argument. - Added RfpNoConfigTest2::testUnreadableRasterReportsGdalError and the synthesized fixture TestData/VRT/ticket1001_unreadable.vrt: a lazy VRT whose source file is deliberately absent, so GDALOpen succeeds and the first pixel read fails, exercising GRFP_111 end to end. Verified with the GDAL unit suite (OK (66 tests)) in the ubuntu22 Debug container. Note: the GDAL provider's Windows message project (RFPMessage.vcproj/.vcxproj) has only ever merged the static RC template, so its message table has always been empty for this provider; the new text still reaches Windows clients because the default strings passed to the NlsMsgGet* calls were updated in step. Wiring it up like the other providers is left for a separate change. Fixes #1001 }}} -- Ticket URL: FDO Feature Data Objects From trac_fdo at osgeo.org Wed Oct 7 10:24:32 2026 From: trac_fdo at osgeo.org (FDO) Date: Wed, 07 Oct 2026 17:24:32 -0000 Subject: [Fdo-trac] [fdo-trac] #615: FdoSpatialOperations incorrectly rejected In-Reply-To: <043.25302e66de509f3a48e674007e38385d@osgeo.org> References: <043.25302e66de509f3a48e674007e38385d@osgeo.org> Message-ID: <058.b4d248b641b15f126cfd78fa26677493@osgeo.org> #615: FdoSpatialOperations incorrectly rejected -------------------------------+----------------------------- Reporter: woutersmit | Owner: brentrobinson Type: defect | Status: closed Priority: major | Milestone: 3.6.0 Component: SQLServer Spatial | Version: 3.5.0 Severity: 1 | Resolution: fixed Keywords: | External ID: -------------------------------+----------------------------- Changes (by jng): * resolution: => fixed * status: new => closed Comment: In [changeset:"8386" 8386]: {{{#!CommitTicketReference repository="" revision="8386" Fix up various provider capabilities to ensure they line up with actual reality. Backed with new tests for relevant providers to verify this. Fixes #615 }}} -- Ticket URL: FDO Feature Data Objects From trac_fdo at osgeo.org Tue Oct 13 01:21:48 2026 From: trac_fdo at osgeo.org (FDO) Date: Tue, 13 Oct 2026 08:21:48 -0000 Subject: [Fdo-trac] [fdo-trac] #1014: Check in doc sources Message-ID: <036.3f0c3b6f52b1edf47f872d3e3109c77d@osgeo.org> #1014: Check in doc sources -----------------------------+---------------------- Reporter: jng | Owner: jng Type: task | Status: assigned Priority: major | Milestone: Component: Documentation | Version: Severity: 3 | Keywords: External ID: | -----------------------------+---------------------- We don't have content sources for the following documentation artifacts: - The Essential FDO - FDO Developer's Guide We will have to de-compile the existing PDF files into some plaintext format (markdown or rst), check these sources in and then integrate a documentation build tool to build new documentation artifacts from these checked in sources. We already use sphinx-doc for the MapGuide Developer's Guide (content is rst files). We can do the same thing here. -- Ticket URL: FDO Feature Data Objects From trac_fdo at osgeo.org Tue Oct 13 04:05:45 2026 From: trac_fdo at osgeo.org (FDO) Date: Tue, 13 Oct 2026 11:05:45 -0000 Subject: [Fdo-trac] [fdo-trac] #227: MySQL Defect : wrong column type in SQLCommand In-Reply-To: <039.f9f3cf06061972dd06520ecdb07822fb@osgeo.org> References: <039.f9f3cf06061972dd06520ecdb07822fb@osgeo.org> Message-ID: <054.08f18af1ea3d89087921c2c1b55fc802@osgeo.org> #227: MySQL Defect : wrong column type in SQLCommand ----------------------------+------------------------- Reporter: bscott | Owner: danstoica Type: defect | Status: closed Priority: major | Milestone: 3.4.0 Component: MySQL Provider | Version: 3.2.0 Severity: 2 | Resolution: fixed Keywords: | External ID: ----------------------------+------------------------- Changes (by jng): * resolution: => fixed * status: new => closed Comment: In [changeset:"8397" 8397]: {{{#!CommitTicketReference repository="" revision="8397" Report the correct column types in MySQL native queries FdoISQLDataReader reported a native FdoISQLCommand query's SMALLINT, MEDIUMINT and INT columns - and its FLOAT columns - as FdoDataType_Double. The MySQL driver's mysql_to_rdbi_type() mapped MYSQL_TYPE_SHORT, MYSQL_TYPE_LONG, MYSQL_TYPE_INT24 and MYSQL_TYPE_FLOAT to RDBI_DOUBLE, each marked "this should be fixed", and FdoRdbmsUtil::DbiToFdoType() turns that into FdoDataType_Double, so callers were told to read an integer column through the Double accessors. The schema manager already got this right (FdoSmPhMySqlColTypeMapper maps a MySQL int to Int32), so only the native query path disagreed with the schema it was describing. The rdbi type also decides how GdbiQueryResult converts the value out of its fetch buffer, so an integer column has to describe as RDBI_SHORT / RDBI_INT / RDBI_LONGLONG and a MySQL FLOAT as RDBI_FLOAT. An unsigned integer column does not fit its signed counterpart's rdbi type, so desc_slct now passes the column's UNSIGNED_FLAG down, and mysql_to_rdbi_type widens an unsigned SMALLINT to RDBI_INT and an unsigned INT to RDBI_LONGLONG - the same widening FdoSmPhMySqlColTypeMapper applies. Without it an unsigned INT holding 4294967295 truncates at fetch time instead of reading as an FDO Int64. Provider: * Providers/GenericRdbms/Src/MySQL/Driver/type.cpp, type.h: mysql_to_rdbi_type() now maps MYSQL_TYPE_SHORT to RDBI_SHORT (RDBI_INT when unsigned), MYSQL_TYPE_INT24 and MYSQL_TYPE_LONG to RDBI_INT (RDBI_LONGLONG when unsigned) and MYSQL_TYPE_FLOAT to RDBI_FLOAT, instead of RDBI_DOUBLE for all four, and takes an is_unsigned flag. MYSQL_TYPE_TINY and MYSQL_TYPE_LONGLONG are unchanged. DECIMAL is deliberately untouched: an FDO Decimal column has no rdbi type to describe it as, and the ODBC driver describes SQL_DECIMAL identically. * Providers/GenericRdbms/Src/MySQL/Driver/desc_slct.cpp: pass (fields[position].flags & UNSIGNED_FLAG) to mysql_to_rdbi_type(). Tests: * MySqlFdoSqlCmdTest::QueryColumnTypes (new): a native query over a table of MySQL SMALLINT, MEDIUMINT, INT, BIGINT, INT UNSIGNED, FLOAT, DOUBLE, VARCHAR and DATETIME columns asserts both the type GetColumnType() reports for each column and that the value still round-trips through the getter that type implies. It failed before the fix with "Column 'smallint_val' is reported as 'Double' but expected 'Int16'". * DataTypeTests::floating and SelectTests::describe asserted the double MySQL used to lie about. Both now take the expected FLOAT column type (and size) from a provider hook whose default preserves the SQL Server expectation (a SQL Server float is 53 bits, so RDBI_DOUBLE). * SelectTests::describe's integer column assertion, commented out with "want RDBI_INT but we get RDBI_DOUBLE", is enabled; both MySQL and SQL Server describe an integer column as RDBI_INT. Verified with the full MySql unit test suite in the baseline ubuntu22 containers against MySQL 5.6: OK (248) in both the Debug (ASan) and Release configurations, up from OK (247). The Debug LeakSanitizer total is 46236 bytes in 491 allocations (46976 in 493 before). Fixes #227 }}} -- Ticket URL: FDO Feature Data Objects From trac_fdo at osgeo.org Tue Oct 13 07:58:57 2026 From: trac_fdo at osgeo.org (FDO) Date: Tue, 13 Oct 2026 14:58:57 -0000 Subject: [Fdo-trac] [fdo-trac] #228: MySQL Defect : Can't retreive tablename in joined query In-Reply-To: <039.18b2408855a843b744709972df86026f@osgeo.org> References: <039.18b2408855a843b744709972df86026f@osgeo.org> Message-ID: <054.2584e2ea91bb9685c9faabf0b5688867@osgeo.org> #228: MySQL Defect : Can't retreive tablename in joined query ----------------------------+------------------------- Reporter: bscott | Owner: danstoica Type: defect | Status: closed Priority: major | Milestone: 3.4.0 Component: MySQL Provider | Version: 3.2.0 Severity: 4 | Resolution: fixed Keywords: | External ID: ----------------------------+------------------------- Changes (by jng): * resolution: => fixed * status: new => closed Comment: In [changeset:"8399" 8399]: {{{#!CommitTicketReference repository="" revision="8399" Fix joined queries reporting indistinguishable column names A native FdoISQLCommand query that selects a same-named column from more than one table reports that one name for every one of them, and FdoISQLDataReader resolves a column name to the first column that has it, so every column after the first was unreachable by name. That is FDO ticket #228, which asked either for a table-qualified name from GetColumnName() or for some other way to tell the columns apart. A table-qualified name was not taken: it changes what a caller receives for every query, it means nothing for a select-list item that is an expression (the reporter's own ticket comment gives "table1.column1 + table2.column2" as the case that rules it out), and it needs a new table- name output on the rdbi_describe_slct contract that every driver would have to supply. The readers already had the disambiguation both interfaces need - a repeat of a select-list name gets a "$" suffix, so a join reports SHARED_COL, SHARED_COL$1, SHARED_COL$2 - and two defects sat behind it, so the GenericRdbms path was broken for the second repeat and the King Oracle path did not disambiguate at all. FdoRdbmsSQLDataReader::GenerateUniqueName() wrote the digit of its suffix with "*(dest + propsize + 1 + idx) = buffer[idx++]", which reads and increments idx without a sequence point; GCC evaluates the right-hand side first, so the digit went one slot past the NUL terminator and the name did not change. A two- table join therefore reported SHARED_COL and a malformed SHARED_COL$, and because the name was never replaced, the retry loop that looks for a name the result set does not already use never terminated: a query with three same-named select-list items hung in ExecuteReader() indefinitely (the loop's counter was observed climbing past 25 with the name unchanged). The same expression in the sibling "name too long" branch also left a gap at dest[2]. Both branches now copy the digit and advance the index in separate statements. c_KgOraSQLDataReader, which is the King Oracle provider's own reader rather than a subclass of the GenericRdbms one, returned the OCI column name for every ordinal and nothing more, so its name-to-index lookup reached only the first column of a repeated name - the original symptom of the ticket, unfixed. Because the suffix is produced by the shared reader, the GenericRdbms fix covers every provider that reads a native query through it (MySQL, PostGIS, ODBC and SQL Server Spatial); King Oracle needed its own. Provider: * Providers/GenericRdbms/Src/Fdo/Other/FdoRdbmsSQLDataReader.cpp: GenerateUniqueName() copies each digit into dest with the index advanced in a second statement, in both the suffix and the "too long" branch, and the sequence-point hazard is noted in a comment. The generated names are unchanged - first repeat "$1", second "$2" - so no other caller of this reader is affected. * Providers/KingOracle/src/Provider/c_KgOraSQLDataReader.cpp, c_KgOraSQLDataReader.h: the constructor builds a new m_ColumnNames collection that holds the reported name of every result set column in ordinal order, via the new MakeUniqueColumnName(), which suffixes a name that a previous column already used (case-insensitively, matching the collection's own lookup). The recognized-type and SDO_GEOMETRY branches add that same name to m_SqlColumns, so the name a caller is given is the name that resolves to its own column. GetColumnName() returns the reported name and now range-checks its index; it previously passed the ordinal to OCI unvalidated. m_ColumnNames is an FdoPtr, so the new collection is released with the reader, and only private headers changed (the class lives under src/Provider, not the installed inc/KingOracle tree), so no shipped layout moves. Tests: * Providers/GenericRdbms/Src/UnitTest/Common/FdoSqlCmdTest.cpp, FdoSqlCmdTest.h: FdoSqlCmdTest::QueryJoinedColumns (new), in the shared provider suite: three tables are each given a key_col and a shared_col, one row is inserted into each, and a three-way join selects shared_col three times. It asserts the reported names are SHARED_COL, SHARED_COL$1 and SHARED_COL$2, that each name reads its own column through GetInt32, and that ExecuteReader() returns at all. It fails before the fix - with two tables the name is "SHARED_COL$" and with three the reader never returns. Registered in the base suite, so MySQL, PostGIS, ODBC and SQL Server Spatial all inherit it. The precondition uses DROP TABLE IF EXISTS inside a catch: a plain failed DROP aborts a PostgreSQL transaction and would poison every statement after it, while the clause itself is newer than some servers this suite targets. * Providers/GenericRdbms/Src/UnitTest/Odbc/OdbcFdoSqlCmdTest.h: a no-op override of QueryJoinedColumns for OdbcAccessFdoSqlCmdTest, alongside the stubs it already has for the other tests that fixture cannot run because it has no SQL-command support. * Providers/KingOracle/src/KgOraUnitTest/SelectTests.cpp, SelectTests.h: SelectTests::SelectJoinedColumns (new) for King Oracle: the same three- way join against Oracle XE 11g, asserting the same three names and that each reads its own value. It failed before the provider fix with the second column reported as SHARED_COL. * Providers/KingOracle/src/KgOraUnitTest/InsertUpdateDeleteTests.cpp: AddBatchRow (was MakeBatchRow returning a Detached raw pointer) now builds the row of a batch insert into an FdoPtr and adds it from there. FdoCollection::Add() takes a reference of its own and does not consume the caller's, so the reference the row factory made was left with no owner - 11 direct LeakSanitizer records of 32 bytes, one per row of the four InsertBatch tests, each anchoring its row's parameter values, their data values, the FdoGeometryValue and the FGF byte array behind it. This fixes a leak introduced with r8398's batch-insert tests and leaves their assertions unchanged. Verified in the baseline ubuntu22 Debug (ASan) build container against the dbs compose MySQL 5.6, PostGIS and Oracle XE 11g. FdoSqlCmdTest goes from OK (9) to OK (10) for MySQL and runs OK (9) for PostGIS; the full MySql and PostGis suites are OK (249) and OK (140) with no direct leak record and no record whose stack refers to the changed code (their LeakSanitizer totals are unchanged at 46236 bytes in 491 allocations and 105212 bytes in 942). KgOraUnitTest is OK (39) with SelectTests OK (3), up from OK (2), and its LeakSanitizer total goes from 6284 bytes in 132 allocations (11 direct, 121 indirect) to 0 bytes. UnitTestOdbc builds with the new override. Fixes #228 }}} -- Ticket URL: FDO Feature Data Objects From trac_fdo at osgeo.org Tue Oct 13 08:28:10 2026 From: trac_fdo at osgeo.org (FDO) Date: Tue, 13 Oct 2026 15:28:10 -0000 Subject: [Fdo-trac] [fdo-trac] #965: Static object destructors not called on Linux In-Reply-To: <036.2b273da8fed9a9c0c2542b21143497c6@osgeo.org> References: <036.2b273da8fed9a9c0c2542b21143497c6@osgeo.org> Message-ID: <051.005f08ccb3eb25dba88c718df2c33977@osgeo.org> #965: Static object destructors not called on Linux ---------------------+----------------------- Reporter: jng | Owner: jng Type: defect | Status: closed Priority: major | Milestone: 4.2.0 Component: FDO API | Version: Severity: 3 | Resolution: wontfix Keywords: | External ID: ---------------------+----------------------- Changes (by jng): * resolution: => wontfix * status: assigned => closed Comment: DeepSeek has determined that the "fix" is more painful than the status quo, so we'll take the position of "don't fix what's not broken" -- Ticket URL: FDO Feature Data Objects From trac_fdo at osgeo.org Tue Oct 13 08:37:46 2026 From: trac_fdo at osgeo.org (FDO) Date: Tue, 13 Oct 2026 15:37:46 -0000 Subject: [Fdo-trac] [fdo-trac] #501: ODBC Provider on XLS Truncates Data In-Reply-To: <045.9f4f39ccceaad623f79e6a70af7932dd@osgeo.org> References: <045.9f4f39ccceaad623f79e6a70af7932dd@osgeo.org> Message-ID: <060.1087a8e39c64feac8c765ea5adb9c541@osgeo.org> #501: ODBC Provider on XLS Truncates Data --------------------------+------------------------- Reporter: crispinatime | Owner: gregboone Type: defect | Status: closed Priority: major | Milestone: 3.5.0 Component: FDO API | Version: 3.3.2 Severity: 3 | Resolution: wontfix Keywords: | External ID: --------------------------+------------------------- Changes (by jng): * resolution: => wontfix * status: assigned => closed Comment: DeepSeek analysis: For unknown reasons, there is a "TABLE" version of this worksheet and a "SYSTEM TABLE" version of this worksheet. The "TABLE" version reports 11 rows (your issue). The "SYSTEM TABLE" version of this worksheet is 13 rows (your expected result). The ODBC provider does not show "SYSTEM TABLE" objects. We could relax this restriction, but that could have undesirable implications for non- Excel data sources that are ODBC accessible. Also .xls is legacy format (everyone should be using .xlsx files by now!) that's too marginal for such a corner-case fix. -- Ticket URL: FDO Feature Data Objects From trac_fdo at osgeo.org Wed Oct 14 02:23:02 2026 From: trac_fdo at osgeo.org (FDO) Date: Wed, 14 Oct 2026 09:23:02 -0000 Subject: [Fdo-trac] [fdo-trac] #734: Problem reading negative Int64 values In-Reply-To: <041.96273c66d3810fb35c59ca146629c264@osgeo.org> References: <041.96273c66d3810fb35c59ca146629c264@osgeo.org> Message-ID: <056.3c4ca8875c5d9a2201c732cb177d96d1@osgeo.org> #734: Problem reading negative Int64 values ---------------------------------+---------------------- Reporter: simonpel | Owner: haris Type: defect | Status: closed Priority: major | Milestone: 3.5.0 Component: KingOracle Provider | Version: 3.5.0 Severity: 3 | Resolution: fixed Keywords: | External ID: ---------------------------------+---------------------- Changes (by jng): * resolution: => fixed * status: new => closed Comment: In [changeset:"8400" 8400]: {{{#!CommitTicketReference repository="" revision="8400" Ticket #734: Negative values and unrecognized OCI conversion failures Ticket #734 ("Problem reading negative Int64 values") reports that reading a negative Int64 returns "GetInt64 : Exception unrecognized" and crashes the client. Two things were behind that, and this change set covers both. Reading the value: the provider narrows the Oracle NUMBER it fetched back to a C integer with OCINumberToInt, and that conversion has to be told the value is signed. The 3.5-era code performed it as OCI_NUMBER_UNSIGNED inside GetLong(), so Oracle rejected every negative value (ORA-01426). GetLong() was replaced by GetInt64() (OCI_NUMBER_SIGNED, sizeof(FdoInt64)) in r7061, which also switched GetInteger() to OCI_NUMBER_SIGNED, so the reported case already passes on this branch; no provider change was needed for it, and what was missing was coverage. Reporting the failure: when an accessor cannot narrow the value it read, OCI reports it through a raw c_Oci_Exception, and that is where the ticket's "Exception unrecognized" comes from - a client cannot interpret that type. The numeric accessors of both readers now raise the FdoCommandException a client can read, carrying the OCI message ("OCI-22053: overflow error"), which also removes c_KgOraReader::GetInt32's catch that printed the error and returned 0: an unreadable value was indistinguishable from a genuine zero. Provider: * c_OCI_API: OciErrorToFdoException() turns the c_Oci_Exception an accessor reported into an FdoCommandException carrying the OCI text, taking over the exception it is given. * c_KgOraReader: GetInt16, GetInt32, GetInt64, GetSingle and GetDouble route their statement accessor's OCI error through it. * c_KgOraSQLDataReader: the same five accessors. Tests: * DataTypeTests::NegativeNumbers reads negative values back through FdoISQLDataReader for every width OCINumberToInt narrows - Int16, Int32 and Int64 (NUMBER(4,0), NUMBER(9,0), NUMBER(19,0)), plus Single, Double and a scaled NUMBER - once with a small negative and once with the smallest value the column can hold, asserting the FDO types reported for the columns too. * DataTypeTests::NegativeFeatureValues covers the feature commands: a negative identity and Int32 are inserted with FdoIInsert and the identity is read back from the command's own reader, then read by an equality filter built from an FdoInt64Value, by a text range filter and through an ordered select, and an update and a delete are executed against a filter matching the negative key. It also asserts that reading the Int64 minimum through GetInt32 raises instead of returning 0. * DataTypeTests::NumberOutOfRange asserts that a NUMBER(19,0) holding 19 nines - one row negative, one positive - fails as an FdoException carrying the OCI text rather than as an unrecognized exception, and that the Int64 minimum, which does fit Int64, is still readable through the same statement. Verified with the full KgOraUnitTest suite against Oracle XE 11g: OK (42) in the Debug (ASan) and Release configurations, the Debug run with no LeakSanitizer report. Both halves were also run against the behaviour they replace: with OCI_NUMBER_UNSIGNED restored in c_Oci_Statement the two value tests fail, and with OciErrorToFdoException rethrowing the raw c_Oci_Exception instead of converting it, the two reporting tests fail - each with an uncaught exception of unknown type, the client-visible form of the error ticket #734 reports - while the pre-existing cases still pass. Fixes #734 }}} -- Ticket URL: FDO Feature Data Objects From trac_fdo at osgeo.org Wed Oct 14 04:09:24 2026 From: trac_fdo at osgeo.org (FDO) Date: Wed, 14 Oct 2026 11:09:24 -0000 Subject: [Fdo-trac] [fdo-trac] #974: Creating a spatial context with a dot (.) in the name makes it un-destroyable In-Reply-To: <036.abdbcc526284ee2dde8c3c6fe3fbb26c@osgeo.org> References: <036.abdbcc526284ee2dde8c3c6fe3fbb26c@osgeo.org> Message-ID: <051.b2490e655e8071fc67ad0d0b94e42f7d@osgeo.org> #974: Creating a spatial context with a dot (.) in the name makes it un- destroyable -------------------------------+------------------------- Reporter: jng | Owner: danstoica Type: defect | Status: closed Priority: major | Milestone: 4.2.0 Component: SQLServer Spatial | Version: 4.1.0 Severity: 3 | Resolution: fixed Keywords: | External ID: -------------------------------+------------------------- Changes (by jng): * resolution: => fixed * status: new => closed Comment: In [changeset:"8402" 8402]: {{{#!CommitTicketReference repository="" revision="8402" Ticket #974, #550: SQL Server Spatial dotted spatial context and missing primary key error Two SQL Server Spatial defects, both reported against this provider. Ticket #974 ("Creating a spatial context with a dot (.) in the name makes it un-destroyable") reports that a spatial context whose name contains a dot cannot be destroyed. In a datastore without a meta-schema a spatial context is recorded as a geometry column of the special f_scinfo table, named after the context, so its spatial index name inherits the dots: "Spatial.Context.With.Dots" becomes f_scinfo_spatial.context.with.dots_si_srid=26741. That name is qualified with an owner - the qualifier of the containing table's name ("dbo.f_scinfo"), or, when that name is itself unqualified, the "dbo" that FdoSmPhSqsMgr::GetRealDbObjectName() prepends to unqualified names. A spatial index is scoped to its table in SQL Server, so the DDL must use the unqualified name, and the code produced it with name.Right(L"."), which returns everything after the first dot. That is only correct for a name that actually carries a qualifier: applied to the name read back from sys.indexes, which does not, it discarded the leading part of the name as well. The name the DROP statement was built from therefore no longer matched the name the index had been created with, and the destroy failed with "Cannot drop the index 'dbo.f_scinfo.with.dots_si_srid=26741', because it does not exist or you do not have permission", leaving the spatial context in place. The owner qualifier is now removed only when the name actually starts with it, so one rule holds for both a name that carries a qualifier (new index) and a name that does not (read back from the database, which is how a later session sees the index). The qualifier is taken from the containing table's name, falling back to "dbo" for the unqualified f_scinfo name, and the remainder of the name - dots included - is kept, which is what makes the same index name reachable from the CREATE and the DROP statement. Ticket #550 ("SQL Spatial - poor error message when trying to insert into a table without a primary key") reports that inserting into a table with no primary key fails with "Creating/Updating a standalone instance for class 'X' is not allowed", which gives no hint of the cause. A table without a primary key reverse-engineers to a class without an identity property, which is the condition CheckClass() rejects, and the message named the class but never the table, although the missing primary key on that table is the whole problem. When the class is backed by a table the exception now names the table and says its primary key is missing; the previous message is kept for a class that has no database object, where there is no table to name. Provider: * Providers/GenericRdbms/Src/SQLServerSpatial/SchemaMgr/Ph/SpatialIndex.cpp: SqsUnqualifiedIndexName() removes the owner qualifier only when the name carries it, taking the qualifier from the containing table's name and defaulting to "dbo" for an unqualified table name. FdoSmPhSqsSpatialIndex::GetDDLName() and Add() use it in place of the name.Right(L".") they used before; the name given to SQL Server for an index without dots is unchanged. * Providers/GenericRdbms/Src/Fdo/Schema/FdoRdbmsSchemaUtil.cpp: CheckClass() throws the new message when the class has no identity property and is backed by a database object, and the previous one otherwise. * Providers/GenericRdbms/Nls/fdordbmsmsg.mc: adds FDORDBMS_551 (MessageId=2776), "Creating/Updating a standalone instance for class '%1$ls' is not allowed because table '%2$ls' has no primary key." Existing ids are untouched; the header the message compiler generates from this file (Inc/Nls/fdordbmsmsg.h) is written by the build and is not under version control. Tests: * SqlServerFdoSpatialContextTest::testDottedSpatialContext creates a spatial context named "Spatial.Context.With.Dots", checks that it is listed, destroys it and checks that it is gone. The destroy step is what failed before this change, with the DROP INDEX error quoted above. * SqlServerFdoInsertTest::testDefect550 builds the ticket's table (char(36) id, geometry and varchar columns, no primary key), sets it as the class of an FdoIInsert and asserts that the exception reports the missing primary key. Verified with the SQL Server Spatial suites in the Debug configuration: FdoSpatialContextTest OK (6), FdoInsertTest OK (14), the two together OK (20), FdoUpdateTest and FdoDeleteTest OK (15), and FdoApplySchemaTest OK (5) - the last being the suite that exercises spatial index names without dots and the regression gate for the qualifier change. Both new tests were also run against the source they replace and failed there: testDottedSpatialContext with the DROP INDEX error, and testDefect550 with the message that did not identify the primary key. A sweep of sys.indexes across all 44 fdo_* test databases confirms that no spatial index name kept an owner qualifier, which is the property the DROP statement depends on. Fixes #974 Fixes #550 }}} -- Ticket URL: FDO Feature Data Objects From trac_fdo at osgeo.org Wed Oct 14 04:09:25 2026 From: trac_fdo at osgeo.org (FDO) Date: Wed, 14 Oct 2026 11:09:25 -0000 Subject: [Fdo-trac] [fdo-trac] #550: SQL Spatial - poor error message when trying to insert into a table without a primary key In-Reply-To: <046.b58f416d1b05c6edd764bb110dd65f32@osgeo.org> References: <046.b58f416d1b05c6edd764bb110dd65f32@osgeo.org> Message-ID: <061.a08e6267e240bef3fef8128120dd2fa9@osgeo.org> #550: SQL Spatial - poor error message when trying to insert into a table without a primary key ---------------------------+----------------------------- Reporter: chriserickson | Owner: brentrobinson Type: defect | Status: closed Priority: major | Milestone: 4.2.0 Component: FDO API | Version: 3.4.0 Severity: 3 | Resolution: fixed Keywords: | External ID: ---------------------------+----------------------------- Changes (by jng): * resolution: => fixed * status: new => closed Comment: In [changeset:"8402" 8402]: {{{#!CommitTicketReference repository="" revision="8402" Ticket #974, #550: SQL Server Spatial dotted spatial context and missing primary key error Two SQL Server Spatial defects, both reported against this provider. Ticket #974 ("Creating a spatial context with a dot (.) in the name makes it un-destroyable") reports that a spatial context whose name contains a dot cannot be destroyed. In a datastore without a meta-schema a spatial context is recorded as a geometry column of the special f_scinfo table, named after the context, so its spatial index name inherits the dots: "Spatial.Context.With.Dots" becomes f_scinfo_spatial.context.with.dots_si_srid=26741. That name is qualified with an owner - the qualifier of the containing table's name ("dbo.f_scinfo"), or, when that name is itself unqualified, the "dbo" that FdoSmPhSqsMgr::GetRealDbObjectName() prepends to unqualified names. A spatial index is scoped to its table in SQL Server, so the DDL must use the unqualified name, and the code produced it with name.Right(L"."), which returns everything after the first dot. That is only correct for a name that actually carries a qualifier: applied to the name read back from sys.indexes, which does not, it discarded the leading part of the name as well. The name the DROP statement was built from therefore no longer matched the name the index had been created with, and the destroy failed with "Cannot drop the index 'dbo.f_scinfo.with.dots_si_srid=26741', because it does not exist or you do not have permission", leaving the spatial context in place. The owner qualifier is now removed only when the name actually starts with it, so one rule holds for both a name that carries a qualifier (new index) and a name that does not (read back from the database, which is how a later session sees the index). The qualifier is taken from the containing table's name, falling back to "dbo" for the unqualified f_scinfo name, and the remainder of the name - dots included - is kept, which is what makes the same index name reachable from the CREATE and the DROP statement. Ticket #550 ("SQL Spatial - poor error message when trying to insert into a table without a primary key") reports that inserting into a table with no primary key fails with "Creating/Updating a standalone instance for class 'X' is not allowed", which gives no hint of the cause. A table without a primary key reverse-engineers to a class without an identity property, which is the condition CheckClass() rejects, and the message named the class but never the table, although the missing primary key on that table is the whole problem. When the class is backed by a table the exception now names the table and says its primary key is missing; the previous message is kept for a class that has no database object, where there is no table to name. Provider: * Providers/GenericRdbms/Src/SQLServerSpatial/SchemaMgr/Ph/SpatialIndex.cpp: SqsUnqualifiedIndexName() removes the owner qualifier only when the name carries it, taking the qualifier from the containing table's name and defaulting to "dbo" for an unqualified table name. FdoSmPhSqsSpatialIndex::GetDDLName() and Add() use it in place of the name.Right(L".") they used before; the name given to SQL Server for an index without dots is unchanged. * Providers/GenericRdbms/Src/Fdo/Schema/FdoRdbmsSchemaUtil.cpp: CheckClass() throws the new message when the class has no identity property and is backed by a database object, and the previous one otherwise. * Providers/GenericRdbms/Nls/fdordbmsmsg.mc: adds FDORDBMS_551 (MessageId=2776), "Creating/Updating a standalone instance for class '%1$ls' is not allowed because table '%2$ls' has no primary key." Existing ids are untouched; the header the message compiler generates from this file (Inc/Nls/fdordbmsmsg.h) is written by the build and is not under version control. Tests: * SqlServerFdoSpatialContextTest::testDottedSpatialContext creates a spatial context named "Spatial.Context.With.Dots", checks that it is listed, destroys it and checks that it is gone. The destroy step is what failed before this change, with the DROP INDEX error quoted above. * SqlServerFdoInsertTest::testDefect550 builds the ticket's table (char(36) id, geometry and varchar columns, no primary key), sets it as the class of an FdoIInsert and asserts that the exception reports the missing primary key. Verified with the SQL Server Spatial suites in the Debug configuration: FdoSpatialContextTest OK (6), FdoInsertTest OK (14), the two together OK (20), FdoUpdateTest and FdoDeleteTest OK (15), and FdoApplySchemaTest OK (5) - the last being the suite that exercises spatial index names without dots and the regression gate for the qualifier change. Both new tests were also run against the source they replace and failed there: testDottedSpatialContext with the DROP INDEX error, and testDefect550 with the message that did not identify the primary key. A sweep of sys.indexes across all 44 fdo_* test databases confirms that no spatial index name kept an owner qualifier, which is the property the DROP statement depends on. Fixes #974 Fixes #550 }}} -- Ticket URL: FDO Feature Data Objects From trac_fdo at osgeo.org Wed Oct 14 05:29:54 2026 From: trac_fdo at osgeo.org (FDO) Date: Wed, 14 Oct 2026 12:29:54 -0000 Subject: [Fdo-trac] [fdo-trac] #1000: PostGIS schema tests should try to trim out extraneous schema before comparison In-Reply-To: <036.29aaf2e8cff610919c524a2d9ebc5b3b@osgeo.org> References: <036.29aaf2e8cff610919c524a2d9ebc5b3b@osgeo.org> Message-ID: <051.074a594d478f7e8aeaec8a1c766b1007@osgeo.org> #1000: PostGIS schema tests should try to trim out extraneous schema before comparison ---------------------------------+---------------------- Reporter: jng | Owner: jng Type: defect | Status: closed Priority: major | Milestone: 4.2.0 Component: PostgreSQL Provider | Version: Severity: 3 | Resolution: fixed Keywords: | External ID: ---------------------------------+---------------------- Changes (by jng): * resolution: => fixed * status: assigned => closed Comment: In [changeset:"8403" 8403]: {{{#!CommitTicketReference repository="" revision="8403" Trim off unknown schemas before dumped schema comparison for GenericRdbms- based provider tests. Only real consumer is the PostgreSQL suite where we can trim off non-public schemas to prevent them from breaking tests that compared dumped schemas with their golden masters. Fixes #1000 }}} -- Ticket URL: FDO Feature Data Objects From trac_fdo at osgeo.org Thu Oct 15 01:31:35 2026 From: trac_fdo at osgeo.org (FDO) Date: Thu, 15 Oct 2026 08:31:35 -0000 Subject: [Fdo-trac] [fdo-trac] #111: GDAL Override schema does not show bounds support In-Reply-To: <039.fe21c334d729c865e3a4455936f6bc74@osgeo.org> References: <039.fe21c334d729c865e3a4455936f6bc74@osgeo.org> Message-ID: <054.28633552d43c3237136ff846dbffabc0@osgeo.org> #111: GDAL Override schema does not show bounds support ---------------------------+------------------------- Reporter: jbirch | Owner: warmerdam Type: defect | Status: closed Priority: minor | Milestone: 3.4.0 Component: GDAL Provider | Version: 3.3.0 Severity: 3 | Resolution: fixed Keywords: | External ID: ---------------------------+------------------------- Changes (by jng): * resolution: => fixed * status: new => closed Comment: In [changeset:"8404" 8404]: {{{#!CommitTicketReference repository="" revision="8404" Update GRFP override XML schema to cover missing elements. Fixes #111 }}} -- Ticket URL: FDO Feature Data Objects From trac_fdo at osgeo.org Thu Oct 15 01:42:47 2026 From: trac_fdo at osgeo.org (FDO) Date: Thu, 15 Oct 2026 08:42:47 -0000 Subject: [Fdo-trac] [fdo-trac] #723: Wrong No Data Value In-Reply-To: <041.afca54291ec8b5c02bf33bcba2148ef6@osgeo.org> References: <041.afca54291ec8b5c02bf33bcba2148ef6@osgeo.org> Message-ID: <056.c78e7d340f572169cf653b9b7090198f@osgeo.org> #723: Wrong No Data Value ----------------------------------------------+------------------------- Reporter: sgamperl | Owner: gregboone Type: defect | Status: closed Priority: major | Milestone: 3.6.0 Component: WMS Provider | Version: 3.4.0 Severity: 1 | Resolution: fixed Keywords: WMS, NullPixelValue, NODATAVALUE | External ID: ----------------------------------------------+------------------------- Changes (by jng): * resolution: => fixed * status: new => closed Comment: In [changeset:"8405" 8405]: {{{#!CommitTicketReference repository="" revision="8405" WMS Provider: only report a null pixel value when the image declares one Fixes #723. FdoWmsImage::_getNullPixelValue() substituted 0 whenever GDALGetRasterNoDataValue() reported that a band had no NODATA value, so IRaster::GetNullPixelValue() always handed back a non-null 0 for the ordinary WMS GetMap response: PNG and JPEG images do not carry a NODATA tag. 0 is a valid pixel value, and a valid palette index for palette data, so the fabricated value both hid the "no null pixel value" state (making the client side IsNull() test useless) and turned the first palette colour into "no data". A null pixel value is now only reported when GDAL reports one, and for RGB/RGBA the packed value is only produced when every component band declares one, so the WMS raster returns NULL as the GDAL provider (FdoRfpBandRaster::GetNullPixelValue()) already does in the same situation. Also fix the GPI_Gray branch of FdoWmsImage::_getDataModel(), which read colorEntry[i].c1 (out of bounds once i > 0) and left the green, blue and alpha channels of each palette entry uninitialised. Gray entries now populate all four channels, with an opaque alpha. Adds the offline WmsTestRaster suite: it builds its datasets with GDAL's MEM driver and drives FdoWmsRasterGdal directly, so it needs no WMS server. Its eight tests cover an absent NODATA value (gray, palette and rgb data models), a declared NODATA of 0, NODATA pass-through (Int16, palette index, all-band rgb) and gray palette population. Validation: WMSUnitTest WmsTestRaster on ubuntu22 amd64, Release OK (8) and Debug OK (8); before the fixes the same suite reported 3 failures (an absent NODATA reported as 0) and 1 failure (gray palette entries). A probe over real GetMap responses from two public WMS servers returned NullPixelValue 0 for PNG/JPEG before the change and NULL after it, while declared NODATA values are still returned. }}} -- Ticket URL: FDO Feature Data Objects From trac_fdo at osgeo.org Thu Oct 15 02:01:22 2026 From: trac_fdo at osgeo.org (FDO) Date: Thu, 15 Oct 2026 09:01:22 -0000 Subject: [Fdo-trac] [fdo-trac] #880: Unavailable SQL Server is blocking MapGuide Server In-Reply-To: <040.cfced0edfc166b47424d4e2ae22ebcf7@osgeo.org> References: <040.cfced0edfc166b47424d4e2ae22ebcf7@osgeo.org> Message-ID: <055.e77fe4278fbbed6e56e4e4972a0bba29@osgeo.org> #880: Unavailable SQL Server is blocking MapGuide Server -------------------------------+--------------------- Reporter: gBecker | Owner: jng Type: defect | Status: new Priority: major | Milestone: Component: SQLServer Spatial | Version: 3.7.0 Severity: 3 | Resolution: Keywords: | External ID: -------------------------------+--------------------- Changes (by jng): * milestone: 3.8.0 => * owner: danstoica => jng Comment: DeepSeek analysis: This is a two-pronged issue: 1. The FDO provider does not support connection/command timeouts 2. The MapGuide connection manager is holding a global mutex when trying to open a FDO connection. If such a connection is opening, it is essentially "holding up" all the other thread requests to an any FDO connection until the open operation completes or fails. So those other threads are blocked, giving the impression of an unresponsive MapGuide Server. Addressing 1 does not address 2. Addressing 2 requires more analysis to determine if we can do more fine-grained locking so that other FDO connection open requests are not being held up. Either way, deleting milestone and revisiting after FDO 4.2 / MGOS 4.0 milestones. -- Ticket URL: FDO Feature Data Objects From trac_fdo at osgeo.org Thu Oct 15 02:09:36 2026 From: trac_fdo at osgeo.org (FDO) Date: Thu, 15 Oct 2026 09:09:36 -0000 Subject: [Fdo-trac] [fdo-trac] #927: SQL Server FDO provider crashes when querying a table with an 'image' column In-Reply-To: <036.3f2cb6c1336800f6d100cc9ace189b06@osgeo.org> References: <036.3f2cb6c1336800f6d100cc9ace189b06@osgeo.org> Message-ID: <051.68c6eeb4ad90b0e5f9d47b5bb1488fed@osgeo.org> #927: SQL Server FDO provider crashes when querying a table with an 'image' column -------------------------------+----------------------- Reporter: jng | Owner: jng Type: defect | Status: closed Priority: major | Milestone: 4.1.0 Component: SQLServer Spatial | Version: Severity: 3 | Resolution: wontfix Keywords: | External ID: -------------------------------+----------------------- Changes (by jng): * resolution: => wontfix * status: new => closed Comment: We are closing as wontfix due to these column types being deprecated and it is very unlikely anyone would be using such column types in present day -- Ticket URL: FDO Feature Data Objects From trac_fdo at osgeo.org Thu Oct 15 02:11:19 2026 From: trac_fdo at osgeo.org (FDO) Date: Thu, 15 Oct 2026 09:11:19 -0000 Subject: [Fdo-trac] [fdo-trac] #824: KingSpatiaLite query issue In-Reply-To: <039.15246f746605e20b1bb2602d069c051f@osgeo.org> References: <039.15246f746605e20b1bb2602d069c051f@osgeo.org> Message-ID: <054.98451c086a92e098e25a6b87d3bf5f69@osgeo.org> #824: KingSpatiaLite query issue --------------------------------+------------------------- Reporter: djonio | Owner: gregboone Type: defect | Status: closed Priority: major | Milestone: 3.5.0 Component: General | Version: 3.5.0 Severity: 3 | Resolution: invalid Keywords: x64 KingSpatiaLite | External ID: --------------------------------+------------------------- Changes (by jng): * resolution: => invalid * status: new => closed Comment: King SpatiaLite provider is not in the FDO source tree. Nothing we can do about this. -- Ticket URL: FDO Feature Data Objects From trac_fdo at osgeo.org Thu Oct 15 03:58:38 2026 From: trac_fdo at osgeo.org (FDO) Date: Thu, 15 Oct 2026 10:58:38 -0000 Subject: [Fdo-trac] [fdo-trac] #229: MySQL provider should use the native MySQL ` instead of " In-Reply-To: <039.c1a465eba33cef5910df970047e4c726@osgeo.org> References: <039.c1a465eba33cef5910df970047e4c726@osgeo.org> Message-ID: <054.064ba08232dbc530ee06e989a6513524@osgeo.org> #229: MySQL provider should use the native MySQL ` instead of " ----------------------------+--------------------- Reporter: bscott | Owner: jng Type: defect | Status: new Priority: minor | Milestone: Component: MySQL Provider | Version: 3.2.0 Severity: 3 | Resolution: Keywords: | External ID: ----------------------------+--------------------- Changes (by jng): * milestone: 3.4.0 => * owner: danstoica => jng -- Ticket URL: FDO Feature Data Objects From trac_fdo at osgeo.org Thu Oct 15 03:59:05 2026 From: trac_fdo at osgeo.org (FDO) Date: Thu, 15 Oct 2026 10:59:05 -0000 Subject: [Fdo-trac] [fdo-trac] #229: MySQL provider should use the native MySQL ` instead of " In-Reply-To: <039.c1a465eba33cef5910df970047e4c726@osgeo.org> References: <039.c1a465eba33cef5910df970047e4c726@osgeo.org> Message-ID: <054.5ffb9f66bdfd1115f7f4606403a1153a@osgeo.org> #229: MySQL provider should use the native MySQL ` instead of " ----------------------------+--------------------- Reporter: bscott | Owner: jng Type: defect | Status: new Priority: minor | Milestone: Component: MySQL Provider | Version: 3.2.0 Severity: 3 | Resolution: Keywords: | External ID: ----------------------------+--------------------- Changes (by jng): * Attachment "ticket229.patch" added. -- Ticket URL: FDO Feature Data Objects From trac_fdo at osgeo.org Thu Oct 15 03:59:57 2026 From: trac_fdo at osgeo.org (FDO) Date: Thu, 15 Oct 2026 10:59:57 -0000 Subject: [Fdo-trac] [fdo-trac] #229: MySQL provider should use the native MySQL ` instead of " In-Reply-To: <039.c1a465eba33cef5910df970047e4c726@osgeo.org> References: <039.c1a465eba33cef5910df970047e4c726@osgeo.org> Message-ID: <054.98c9df7d0541f0af837d2df2c813aaab@osgeo.org> #229: MySQL provider should use the native MySQL ` instead of " ----------------------------+--------------------- Reporter: bscott | Owner: jng Type: defect | Status: new Priority: minor | Milestone: Component: MySQL Provider | Version: 3.2.0 Severity: 3 | Resolution: Keywords: | External ID: ----------------------------+--------------------- Comment (by jng): Added proposed patch. Will revisit after 4.2 -- Ticket URL: FDO Feature Data Objects From trac_fdo at osgeo.org Thu Oct 15 05:34:25 2026 From: trac_fdo at osgeo.org (FDO) Date: Thu, 15 Oct 2026 12:34:25 -0000 Subject: [Fdo-trac] [fdo-trac] #675: FeatureSchema/FeatureSchemaCollection WriteXml() disregards indentation settings In-Reply-To: <036.3f61c54ae1b727dbfe43e3015ede8574@osgeo.org> References: <036.3f61c54ae1b727dbfe43e3015ede8574@osgeo.org> Message-ID: <051.ff9b477e0ea58c2ef5c7d9743803a826@osgeo.org> #675: FeatureSchema/FeatureSchemaCollection WriteXml() disregards indentation settings ---------------------+----------------------------- Reporter: jng | Owner: brentrobinson Type: defect | Status: closed Priority: minor | Milestone: 3.6.0 Component: FDO API | Version: 3.5.0 Severity: 3 | Resolution: fixed Keywords: | External ID: ---------------------+----------------------------- Changes (by jng): * resolution: => fixed * status: new => closed Comment: In [changeset:"8408" 8408]: {{{#!CommitTicketReference repository="" revision="8408" Honor XML flags and line formatting when serializing features and schemas Fixes #675. Fixes #738. Both tickets were reported against the .NET managed wrapper, which forwards its arguments straight to these C++ classes, so the defects are in the C++ implementations and are fixed there. No managed code change is needed. #738 XmlFeatureSerialiser Does not Handle XMLFlags. FdoXmlFeatureSerializer::XmlSerialize() used its flags only for the FeatureCollection and featureMember elements that it writes itself. The feature writer and its feature property writer kept the flags they were created with, which is NULL whenever an application sets the flags on the serializer alone, as the ticket's failing example does. The features were then written with the default flags: GML 3.1.1 was requested and GML 2.1.2 geometry was produced, and the flags' default namespace prefix, srs name, coordinate system transform and gml:id relate properties were all ignored. The feature writer and feature property writer gain GetFeatureFlags()/SetFeatureFlags() and GetFlags()/SetFlags(), so that the serializer can see whether they were given flags of their own; a writer that already has flags is still left exactly as it is. XmlSerialize() applies the flags it is given to both writers when they hold none, and restores them afterwards, including when an exception unwinds the call. The writers carry the flags while the features are written, so sub-writers created for object and association properties inherit them, and the two examples in the ticket now produce the same document. #675 FeatureSchema/FeatureSchemaCollection WriteXml() disregards indentation settings. A Feature Schema has no external form of its own: FdoXmlSerializable::WriteXml() writes it in FDO's internal format to a temporary document, converts that to GML with an XSL transform and hands the transform's output to the caller's writer with WriteBytes(). Those bytes go straight to the stream, past FdoXmlWriter's line formatting, so a writer created with LineFormat_Indent produced a document with no line breaks at all. The internal writer was also created with the default line format, which the transform's output inherited. FdoXmlWriter gains WriteXmlText(), which writes XML text through the writer so that its line format is applied to it: a markup element starts a line of its own, indented to its depth in the document, while content, and the markup that follows content, are written verbatim. The scan for markup understands attribute values that contain '>' under either quoting character, comments, CDATA sections and processing instructions, and drops the XML declaration, since the writer writes its own. GetLineFormat() tells FdoXmlSerializable::WriteXml() when a line format was requested; it then transforms into a temporary document and writes that document through the caller's writer. When no line format is requested the transform's output still reaches the caller byte for byte as before. Tests: XmlTest::testWriteXmlText drives WriteXmlText() directly (declaration, an attribute value holding '>', a single quoted attribute, a comment, a CDATA section, a processing instruction, mixed content and an empty element). GmlWriteTest::testGML3SimpleFeatureNoWriterFlags serializes the same features twice, once with the flags on the writer, which worked, and once with them only on the serializer, and requires the two documents to be identical; it also checks that the serializer did not leave the flags it applied behind. SchemaTest::testXmlWriteIndent writes a schema, a single schema collection and a two schema collection to an indenting writer, and requires the indentation, an unindented document that differs only in the whitespace between elements, and a result that still parses. All three failed before these fixes, on the missing indentation and on GML 2.1.2 in the output where 3.1.1 was expected. Validation: FDOCore UnitTest on ubuntu22 amd64, Debug OK (126) and Release OK (126), against OK (123) for the same tree before the change. The Debug run reports 0 direct and 50 indirect LeakSanitizer records, 220980 bytes in 2418 allocations, the same totals the suite reported before the change. API/ABI: the cycle is in freeze mode. Four of the changed headers ship in the SDK include tree, but the additions are non-virtual member functions and inline getters, with no change to a data member or to a vtable. nm -D over libFDO against the fdosdk 8364 baseline reports no removed symbols and five added, no provider in that SDK has an undefined FdoXml reference the new library does not define, and a sizeof probe compiled against the baseline include tree and against the new one reports the same sizes for every affected class. }}} -- Ticket URL: FDO Feature Data Objects From trac_fdo at osgeo.org Thu Oct 15 05:34:25 2026 From: trac_fdo at osgeo.org (FDO) Date: Thu, 15 Oct 2026 12:34:25 -0000 Subject: [Fdo-trac] [fdo-trac] #738: XmlFeatureSerialiser Does not Handle XMLFlags In-Reply-To: <045.cdf519bf0daa17d8ca41f506f3d86c02@osgeo.org> References: <045.cdf519bf0daa17d8ca41f506f3d86c02@osgeo.org> Message-ID: <060.a58ba02ad6467399085d182eebbadd31@osgeo.org> #738: XmlFeatureSerialiser Does not Handle XMLFlags --------------------------+------------------------- Reporter: crispinatime | Owner: gregboone Type: defect | Status: closed Priority: minor | Milestone: 3.6.0 Component: FDO API | Version: 3.6.0 Severity: 3 | Resolution: fixed Keywords: | External ID: --------------------------+------------------------- Changes (by jng): * resolution: => fixed * status: new => closed Comment: In [changeset:"8408" 8408]: {{{#!CommitTicketReference repository="" revision="8408" Honor XML flags and line formatting when serializing features and schemas Fixes #675. Fixes #738. Both tickets were reported against the .NET managed wrapper, which forwards its arguments straight to these C++ classes, so the defects are in the C++ implementations and are fixed there. No managed code change is needed. #738 XmlFeatureSerialiser Does not Handle XMLFlags. FdoXmlFeatureSerializer::XmlSerialize() used its flags only for the FeatureCollection and featureMember elements that it writes itself. The feature writer and its feature property writer kept the flags they were created with, which is NULL whenever an application sets the flags on the serializer alone, as the ticket's failing example does. The features were then written with the default flags: GML 3.1.1 was requested and GML 2.1.2 geometry was produced, and the flags' default namespace prefix, srs name, coordinate system transform and gml:id relate properties were all ignored. The feature writer and feature property writer gain GetFeatureFlags()/SetFeatureFlags() and GetFlags()/SetFlags(), so that the serializer can see whether they were given flags of their own; a writer that already has flags is still left exactly as it is. XmlSerialize() applies the flags it is given to both writers when they hold none, and restores them afterwards, including when an exception unwinds the call. The writers carry the flags while the features are written, so sub-writers created for object and association properties inherit them, and the two examples in the ticket now produce the same document. #675 FeatureSchema/FeatureSchemaCollection WriteXml() disregards indentation settings. A Feature Schema has no external form of its own: FdoXmlSerializable::WriteXml() writes it in FDO's internal format to a temporary document, converts that to GML with an XSL transform and hands the transform's output to the caller's writer with WriteBytes(). Those bytes go straight to the stream, past FdoXmlWriter's line formatting, so a writer created with LineFormat_Indent produced a document with no line breaks at all. The internal writer was also created with the default line format, which the transform's output inherited. FdoXmlWriter gains WriteXmlText(), which writes XML text through the writer so that its line format is applied to it: a markup element starts a line of its own, indented to its depth in the document, while content, and the markup that follows content, are written verbatim. The scan for markup understands attribute values that contain '>' under either quoting character, comments, CDATA sections and processing instructions, and drops the XML declaration, since the writer writes its own. GetLineFormat() tells FdoXmlSerializable::WriteXml() when a line format was requested; it then transforms into a temporary document and writes that document through the caller's writer. When no line format is requested the transform's output still reaches the caller byte for byte as before. Tests: XmlTest::testWriteXmlText drives WriteXmlText() directly (declaration, an attribute value holding '>', a single quoted attribute, a comment, a CDATA section, a processing instruction, mixed content and an empty element). GmlWriteTest::testGML3SimpleFeatureNoWriterFlags serializes the same features twice, once with the flags on the writer, which worked, and once with them only on the serializer, and requires the two documents to be identical; it also checks that the serializer did not leave the flags it applied behind. SchemaTest::testXmlWriteIndent writes a schema, a single schema collection and a two schema collection to an indenting writer, and requires the indentation, an unindented document that differs only in the whitespace between elements, and a result that still parses. All three failed before these fixes, on the missing indentation and on GML 2.1.2 in the output where 3.1.1 was expected. Validation: FDOCore UnitTest on ubuntu22 amd64, Debug OK (126) and Release OK (126), against OK (123) for the same tree before the change. The Debug run reports 0 direct and 50 indirect LeakSanitizer records, 220980 bytes in 2418 allocations, the same totals the suite reported before the change. API/ABI: the cycle is in freeze mode. Four of the changed headers ship in the SDK include tree, but the additions are non-virtual member functions and inline getters, with no change to a data member or to a vtable. nm -D over libFDO against the fdosdk 8364 baseline reports no removed symbols and five added, no provider in that SDK has an undefined FdoXml reference the new library does not define, and a sizeof probe compiled against the baseline include tree and against the new one reports the same sizes for every affected class. }}} -- Ticket URL: FDO Feature Data Objects From trac_fdo at osgeo.org Thu Oct 15 05:43:19 2026 From: trac_fdo at osgeo.org (FDO) Date: Thu, 15 Oct 2026 12:43:19 -0000 Subject: [Fdo-trac] [fdo-trac] #744: RDBMS: Incremental DescribeSchema tuning. In-Reply-To: <046.0d888e41e09e5a3fc3d5bec10774fabf@osgeo.org> References: <046.0d888e41e09e5a3fc3d5bec10774fabf@osgeo.org> Message-ID: <061.ff49d6a2bc0b58abc41abf7ba6b14778@osgeo.org> #744: RDBMS: Incremental DescribeSchema tuning. -------------------------------------------------+------------------------- Reporter: brentrobinson | Owner: | brentrobinson Type: enhancement | Status: closed Priority: major | Milestone: 3.6.0 Component: GenericRdbms API | Version: 3.6.0 Severity: 3 | Resolution: fixed Keywords: incremental DescribeSchema | External ID: performance | -------------------------------------------------+------------------------- Changes (by jng): * resolution: => fixed * status: assigned => closed Comment: Fixed r8392 -- Ticket URL: FDO Feature Data Objects From trac_fdo at osgeo.org Thu Oct 15 06:17:42 2026 From: trac_fdo at osgeo.org (FDO) Date: Thu, 15 Oct 2026 13:17:42 -0000 Subject: [Fdo-trac] [fdo-trac] #740: Properties with NULL Values are not Included in XML Output In-Reply-To: <045.5015bde4e5b6128013d805cfd917de0c@osgeo.org> References: <045.5015bde4e5b6128013d805cfd917de0c@osgeo.org> Message-ID: <060.19ebf16323f01ff2b71ceab79f146ded@osgeo.org> #740: Properties with NULL Values are not Included in XML Output -----------------------------------------+----------------------------- Reporter: crispinatime | Owner: brentrobinson Type: defect | Status: closed Priority: minor | Milestone: 3.6.0 Component: FDO API | Version: 3.6.0 Severity: 3 | Resolution: fixed Keywords: xmlFeatureSerialize XML GML | External ID: -----------------------------------------+----------------------------- Changes (by jng): * resolution: => fixed * status: new => closed Comment: In [changeset:"8409" 8409]: {{{#!CommitTicketReference repository="" revision="8409" Serialize null property values as xsi:nil elements Fixes #740. #740 Properties with NULL Values are not Included in XML Output. FdoXmlFeatureSerializer::XmlSerialize() discarded every property whose value the feature reader reported as null, so the features written by one call had different shapes: a record with a null property was missing that property element altogether, and the gml:featureMembers of an export carried different properties from record to record. A property that the reader reports without a value is now written as a property element with an xsi:nil="true" attribute, which is how XML Schema and GML represent a null value, so every feature written by a call carries the same property elements. Nothing is written, as before, for a property the reader does not report at all - one left out of the select, or one of the GML name/description/id relate properties, whose names ("gml/name") are not element names - and object and association properties still go through their own sub-writers, which write a feature collection and write nothing when it has no members. The managed wrapper forwards its arguments straight to these classes, so no managed code change is needed. * FeatureSerializer.cpp: _writeProperty() writes a null property that the reader reports (GetPropertyIndex() finds it among the properties of the feature being read) and that has a value of its own to be missing (a data or a geometric property) as a property value with no value, which is FDO's null value for a property. * FeaturePropertyWriter.cpp: WriteProperty() writes an FdoPropertyValue that has no value as , and declares the xsi prefix on the property element itself when the caller has not already declared it in scope. A value-only write writes nothing, since a null property's only content is the attribute. * FeaturePropertyReaderImpl.cpp: an element carrying xsi:nil="true", or the other XML Schema literal "1", is a property with no value: its content is not parsed and the property is reported to the feature handler with no value, so that the feature reports it as null instead of as an empty value or an empty geometry. * FeatureReaderImpl.cpp: AddDataProperty() registers the name of a property that is reported with no value, so that IsNull() reports it as null while it stays part of the feature. GetPropertyIndex() and GetPropertyName() reported the property list of the reader itself, which for a reader over a feature collection is empty; they now report that of the feature being read, as IsNull() and GetString() already did. * FeatureSerializer.h, FeaturePropertyWriter.h: document what a null property value is written as. Tests: GmlWriteTest::testNullProperty serializes a reader whose int32Prop, stringProp and geoProp have no value, requires each of its two features to carry all three as xsi:nil elements, and then reads the document back and requires them to come back as null properties of the feature, with the properties that do have values untouched. GmlWriteTest::testWriteNullProperty drives the property writer directly, with a property value that has no value and one that has, and requires the first to be the xsi:nil element with the XMLSchema-instance namespace declared on it, since the caller declared none. GmlTest::testNullProperty reads a document containing xsi:nil="true", xsi:nil="1", xsi:nil="false" and an empty element, and requires the first two to be null and the last two to keep their (empty) values. All three failed before the fix: no xsi:nil element was written for a null property, the property writer dereferenced a null value, and an xsi:nil element in a document was read as an empty value rather than as a null. Validation: FDOCore UnitTest on ubuntu22 amd64, Debug OK (129) and Release OK (129), against OK (126) for the same tree before the change; the three new tests are the difference. The Debug run reports 0 direct and 50 indirect LeakSanitizer records, 220980 bytes in 2418 allocations, the same totals the suite reported before the change. UnitTestMySql OK (249), which includes MySqlFdoImportExportTest OK (4), the suite that round-trips features through the XML serializer and the XML reader, and its LeakSanitizer report is also unchanged (0 direct, 318 indirect, 46236 bytes in 491 allocations). API/ABI: the cycle is in freeze mode, and no provider-facing surface moves. The only shipped headers touched are FeatureSerializer.h and FeaturePropertyWriter.h, in comments; the new code is file-local. nm -D over libFDO against the fdosdk 8364 baseline reports no removed symbols, and the five symbols it reports as added are the ones the previous change added. }}} -- Ticket URL: FDO Feature Data Objects From trac_fdo at osgeo.org Thu Oct 15 08:51:08 2026 From: trac_fdo at osgeo.org (FDO) Date: Thu, 15 Oct 2026 15:51:08 -0000 Subject: [Fdo-trac] [fdo-trac] #340: SDF Provider defect : Not in and not like has wrong behavior with null values In-Reply-To: <039.c64e5fbeb7df99ce6f15f81b66b2e320@osgeo.org> References: <039.c64e5fbeb7df99ce6f15f81b66b2e320@osgeo.org> Message-ID: <054.259b00794eca4c7c79bd263be5f6ff06@osgeo.org> #340: SDF Provider defect : Not in and not like has wrong behavior with null values --------------------------+-------------------------------- Reporter: bscott | Owner: romicadascalescu Type: defect | Status: closed Priority: major | Milestone: 4.2.0 Component: SDF Provider | Version: 3.2.0 Severity: 3 | Resolution: fixed Keywords: | External ID: --------------------------+-------------------------------- Changes (by jng): * resolution: => fixed * status: new => closed Comment: In [changeset:"8410" 8410]: {{{#!CommitTicketReference repository="" revision="8410" Fix incorrect handling of NULL values within an IN condition. This is an Expression Engine level issue, so known downstream consumers that delegate handling this condition to the Expression Engine have new covering tests. Fixes #340 }}} -- Ticket URL: FDO Feature Data Objects