From maxime.schoemans at ulb.be Mon Apr 8 09:21:07 2024 From: maxime.schoemans at ulb.be (SCHOEMANS Maxime) Date: Mon, 8 Apr 2024 16:21:07 +0000 Subject: Joint release 1.1 of MobilityDB, MEOS, and PyMEOS Message-ID: <6cac4d93-9d20-44af-84ae-185e709251a7@ulb.be> The MobilityDB team is proud to announce that the joint release 1.1 of MobilityDB, MEOS, and PyMEOS https://github.com/MobilityDB/MobilityDB/releases/tag/v1.1.1 https://github.com/MobilityDB/PyMEOS/releases/tag/pymeos-cffi-1.1.0 is now available for download. This includes release 1.1.0 as well as a micro release 1.1.1 mainly aimed at ARM64. MobilityDB 1.1.0 Feature Highlights ----------------------------------- MobilityDB 1.1 is a major revision with respect to the initial version 1.0. The most important change in version 1.1 was to extract the core functionality for temporal and spatiotemporal data management from MobilityDB into the Mobility Engine Open Source (MEOS) C library. https://libmeos.org/ In this way, the same functionality provided by MobilityDB in a database environment is available in a C program to be used, for example, in a streaming environment. The MEOS library for mobility management provides similar functionality as the Geometry Engine Open Source (GEOS) C/C++ library for computational geometry. PyMEOS is a library built on top of MEOS that provides all of its functionality wrapped in a set of Python classes. https://github.com/MobilityDB/PyMEOS Several changes were necessary with respect to MobilityDB version 1.0 to enable the above. An important one was the definition of new data types span and spanset, which provide similar functionality to the PostgreSQL data types range and multirange but can also be used in various programming environments regardless of PostgreSQL. These are template types, which means that they are containers of other types, in a similar way as lists and arrays contains values of other types. Furthermore, a new template data type set was also added. Therefore, the types timestampset, period, and periodset in version 1.0 are replaced by the types tstzset, tstzspan, and tstzspanset in version 1.1. MobilityDB 1.1 also includes several bugfixes and performance improvements compared to 1.0. Finally, the API of MEOS and MobilityDB was streamlined to improve usability and to facilitate the other bindings that are currently being developed. For detailed information regarding the MobilityDB and MEOS 1.1 API refer to the pregenerated documentation at https://mobilitydb.github.io/MobilityDB/ MobilityDB 1.1.1 Feature Highlights ----------------------------------- This is mainly a bug fix release allowing MobilityDB and MEOS to run on ARM64 architecture. It also fixes compilation issues when using Postgres 12 and fixes bugs in ever/always spatial relationships. Best regards, The MobilityDB Team -------------- next part -------------- An HTML attachment was scrubbed... URL: From pramsey at cleverelephant.ca Fri Apr 19 10:17:49 2024 From: pramsey at cleverelephant.ca (Paul Ramsey) Date: Fri, 19 Apr 2024 10:17:49 -0700 Subject: Long transactions Message-ID: How do we feel about removing the ?long transaction? code? doc/reference_transaction.xml extras/WFS_locks postgis/long_xact.sql.in postgis/uninstall_long_xact.sql.in regress/core/long_xact.sql It was originally written in hopes that WFS services might use them so that it would be possible to have shared lock management in the database, but that never actually happened. So it?s been fallow for going on 20 years. ??? P From lr at pcorp.us Sat Apr 20 22:00:16 2024 From: lr at pcorp.us (Regina Obe) Date: Sun, 21 Apr 2024 01:00:16 -0400 Subject: Long transactions In-Reply-To: References: Message-ID: <002d01da93a8$cd9cb900$68d62b00$@pcorp.us> > How do we feel about removing the ?long transaction? code? > > doc/reference_transaction.xml > extras/WFS_locks > postgis/long_xact.sql.in > postgis/uninstall_long_xact.sql.in > regress/core/long_xact.sql > > It was originally written in hopes that WFS services might use them so that it > would be possible to have shared lock management in the database, but that > never actually happened. So it?s been fallow for going on 20 years. > > ??? > > P= Sandro and I were discussing this a couple of days ago, that we'll need something like that for topology locking, But I think you are probably right given know one has looked at that piece of code in 20 years, would be better to start from scratch anyway if we need such a thing. So I'm okay with you ripping it out. Sandro - any thoughts on the matter? From strk at kbt.io Mon Apr 22 08:15:08 2024 From: strk at kbt.io (Sandro Santilli) Date: Mon, 22 Apr 2024 17:15:08 +0200 Subject: Long transactions In-Reply-To: <002d01da93a8$cd9cb900$68d62b00$@pcorp.us> References: <002d01da93a8$cd9cb900$68d62b00$@pcorp.us> Message-ID: On Sun, Apr 21, 2024 at 01:00:16AM -0400, Regina Obe wrote: > > How do we feel about removing the ?long transaction? code? > > > > doc/reference_transaction.xml > > extras/WFS_locks > > postgis/long_xact.sql.in > > postgis/uninstall_long_xact.sql.in > > regress/core/long_xact.sql > > > > It was originally written in hopes that WFS services might use them so that it > > would be possible to have shared lock management in the database, but that > > never actually happened. So it?s been fallow for going on 20 years. > > > > ??? > > > > P= > Sandro and I were discussing this a couple of days ago, that we'll need something like that for topology locking, > But I think you are probably right given know one has looked at that piece of code in 20 years, would be better to start from scratch > anyway if we need such a thing. So I'm okay with you ripping it out. > > Sandro - any thoughts on the matter? Feel free to remove it, we have a way to dig it back if we need it for reference. --strk; -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: not available URL: From pramsey at cleverelephant.ca Mon Apr 22 09:07:41 2024 From: pramsey at cleverelephant.ca (Paul Ramsey) Date: Mon, 22 Apr 2024 09:07:41 -0700 Subject: Long transactions In-Reply-To: References: <002d01da93a8$cd9cb900$68d62b00$@pcorp.us> Message-ID: <34A53ADB-F06B-4D94-B482-A6FADC5BEAE3@cleverelephant.ca> This is done now. > On Apr 22, 2024, at 8:15 AM, Sandro Santilli wrote: > > On Sun, Apr 21, 2024 at 01:00:16AM -0400, Regina Obe wrote: >>> How do we feel about removing the ?long transaction? code? >>> >>> doc/reference_transaction.xml >>> extras/WFS_locks >>> postgis/long_xact.sql.in >>> postgis/uninstall_long_xact.sql.in >>> regress/core/long_xact.sql >>> >>> It was originally written in hopes that WFS services might use them so that it >>> would be possible to have shared lock management in the database, but that >>> never actually happened. So it?s been fallow for going on 20 years. >>> >>> ??? >>> >>> P= >> Sandro and I were discussing this a couple of days ago, that we'll need something like that for topology locking, >> But I think you are probably right given know one has looked at that piece of code in 20 years, would be better to start from scratch >> anyway if we need such a thing. So I'm okay with you ripping it out. >> >> Sandro - any thoughts on the matter? > > Feel free to remove it, we have a way to dig it back if we need it > for reference. > > --strk;