public inbox for [email protected]
help / color / mirror / Atom feedRegarding useObjects
14+ messages / 5 participants
[nested] [flat]
* Regarding useObjects
@ 2023-09-26 15:38 Achilleas Mantzios - cloud <[email protected]>
0 siblings, 1 reply; 14+ messages in thread
From: Achilleas Mantzios - cloud @ 2023-09-26 15:38 UTC (permalink / raw)
To: pgsql-jdbc
Dear All
I see support for useObjects was dropped some time in 2020, with this
commit : 529e5dc3a8f071ad4946daf3bde1422c21a99524 .
Desperate mode question : was it replaced by smth else ? Any workaround ?
Serious mode question : Since eventually we'll have to bite the bullet
and do an upgrade, how would you propose dealing with 1000s lines of
java code using arrays of primitives ?
thank you
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: Regarding useObjects
@ 2023-09-26 16:07 Vladimir Sitnikov <[email protected]>
parent: Achilleas Mantzios - cloud <[email protected]>
0 siblings, 1 reply; 14+ messages in thread
From: Vladimir Sitnikov @ 2023-09-26 16:07 UTC (permalink / raw)
To: Achilleas Mantzios - cloud <[email protected]>; +Cc: pgsql-jdbc
> I see support for useObjects was dropped some time in 2020, with this commit : 529e5dc3a8f071ad4946daf3bde1422c21a99524 .
Could you provide a test case that demonstrates the failure?
It is hard to understand what you mean by "useObjects was dropped"
Vladimir
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: Regarding useObjects
@ 2023-09-26 16:58 Achilleas Mantzios <[email protected]>
parent: Vladimir Sitnikov <[email protected]>
0 siblings, 1 reply; 14+ messages in thread
From: Achilleas Mantzios @ 2023-09-26 16:58 UTC (permalink / raw)
To: Vladimir Sitnikov <[email protected]>; +Cc: pgsql-jdbc
Στις 26/9/23 19:07, ο/η Vladimir Sitnikov έγραψε:
>> I see support for useObjects was dropped some time in 2020, with this commit : 529e5dc3a8f071ad4946daf3bde1422c21a99524 .
> Could you provide a test case that demonstrates the failure?
> It is hard to understand what you mean by "useObjects was dropped"
There used to be a variable inside :
src/main/java/org/postgresql/jdbc/PgArray.java which was like :
private final boolean useObjects;
this.useObjects = true;
so there was the option to change this to false and recompile. This
variable was removed between REL42.2.0 and REL42.3.0 . So not quite
support, sorry for my wording.
>
> Vladimir
--
Achilleas Mantzios
IT DEV - HEAD
IT DEPT
Dynacom Tankers Mgmt
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: Regarding useObjects
@ 2023-09-27 06:03 Vladimir Sitnikov <[email protected]>
parent: Achilleas Mantzios <[email protected]>
0 siblings, 1 reply; 14+ messages in thread
From: Vladimir Sitnikov @ 2023-09-27 06:03 UTC (permalink / raw)
To: Achilleas Mantzios <[email protected]>; +Cc: pgsql-jdbc
> so there was the option to change this to false and recompile
We try doing our best to keep backward compatibility both
compilation-wise and behaviour-wise.
However, we treat "private fields and methods" as private, and we do
not expect people would depend on them.
If you have to modify sources or depend on private APIs I would
suggest raising an issue or PR so it could be incorporated
into the driver itself.
Would you please provide a test case of what you are doing with PgArray?
What is exactly the sequence of JDBC calls, the actual and the
expected outcomes in your case?
The mentioned "useObjects" has been removed in
https://github.com/pgjdbc/pgjdbc/pull/1194 (Refactor decoding arrays)
Vladimir
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: Regarding useObjects
@ 2023-09-27 08:59 Achilleas Mantzios - cloud <[email protected]>
parent: Vladimir Sitnikov <[email protected]>
0 siblings, 1 reply; 14+ messages in thread
From: Achilleas Mantzios - cloud @ 2023-09-27 08:59 UTC (permalink / raw)
To: Vladimir Sitnikov <[email protected]>; +Cc: pgsql-jdbc
Good Day Vladimir
On 9/27/23 09:03, Vladimir Sitnikov wrote:
>> so there was the option to change this to false and recompile
> We try doing our best to keep backward compatibility both
> compilation-wise and behaviour-wise.
> However, we treat "private fields and methods" as private, and we do
> not expect people would depend on them.
> If you have to modify sources or depend on private APIs I would
> suggest raising an issue or PR so it could be incorporated
> into the driver itself.
>
> Would you please provide a test case of what you are doing with PgArray?
> What is exactly the sequence of JDBC calls, the actual and the
> expected outcomes in your case?
E.g. for the case of floats, we have to change all:
java.sql.Array arr = rs.getArray(1);
Object objarr = arr.getArray();
float flarr[] = (float[]) objarr;
to
java.sql.Array arr = rs.getArray(1);
Object objarr = arr.getArray();
Float flarr[] = (Float[]) objarr;
>
> The mentioned "useObjects" has been removed in
> https://github.com/pgjdbc/pgjdbc/pull/1194 (Refactor decoding arrays)
>
> Vladimir
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: Regarding useObjects
@ 2023-09-27 09:44 Dave Cramer <[email protected]>
parent: Achilleas Mantzios - cloud <[email protected]>
0 siblings, 2 replies; 14+ messages in thread
From: Dave Cramer @ 2023-09-27 09:44 UTC (permalink / raw)
To: Achilleas Mantzios - cloud <[email protected]>; +Cc: Vladimir Sitnikov <[email protected]>; pgsql-jdbc
On Wed, 27 Sept 2023 at 05:00, Achilleas Mantzios - cloud <
[email protected]> wrote:
> Good Day Vladimir
>
> On 9/27/23 09:03, Vladimir Sitnikov wrote:
> >> so there was the option to change this to false and recompile
> > We try doing our best to keep backward compatibility both
> > compilation-wise and behaviour-wise.
> > However, we treat "private fields and methods" as private, and we do
> > not expect people would depend on them.
> > If you have to modify sources or depend on private APIs I would
> > suggest raising an issue or PR so it could be incorporated
> > into the driver itself.
> >
> > Would you please provide a test case of what you are doing with PgArray?
> > What is exactly the sequence of JDBC calls, the actual and the
> > expected outcomes in your case?
>
> E.g. for the case of floats, we have to change all:
>
> java.sql.Array arr = rs.getArray(1);
>
> Object objarr = arr.getArray();
>
> float flarr[] = (float[]) objarr;
>
> to
>
> java.sql.Array arr = rs.getArray(1);
>
> Object objarr = arr.getArray();
>
> Float flarr[] = (Float[]) objarr;
>
So the problem with using float instead of Float is that it is impossible
to have a null float and arrays can have nulls.
Dave
>
> >
> > The mentioned "useObjects" has been removed in
> > https://github.com/pgjdbc/pgjdbc/pull/1194 (Refactor decoding arrays)
> >
> > Vladimir
>
>
>
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: Regarding useObjects
@ 2023-09-27 09:55 Vladimir Sitnikov <[email protected]>
parent: Dave Cramer <[email protected]>
1 sibling, 1 reply; 14+ messages in thread
From: Vladimir Sitnikov @ 2023-09-27 09:55 UTC (permalink / raw)
To: Dave Cramer <[email protected]>; Achilleas Mantzios - cloud <[email protected]>; +Cc: pgsql-jdbc
> So the problem with using float instead of Float is that it is impossible
to have a null float and arrays can have nulls.
There's a feature request for retrieving primitive arrays:
https://github.com/pgjdbc/pgjdbc/issues/2939
Vladimir
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: Regarding useObjects
@ 2023-09-27 10:00 Achilleas Mantzios - cloud <[email protected]>
parent: Dave Cramer <[email protected]>
1 sibling, 0 replies; 14+ messages in thread
From: Achilleas Mantzios - cloud @ 2023-09-27 10:00 UTC (permalink / raw)
To: Dave Cramer <[email protected]>; +Cc: Vladimir Sitnikov <[email protected]>; pgsql-jdbc
On 9/27/23 12:44, Dave Cramer wrote:
>
>
> On Wed, 27 Sept 2023 at 05:00, Achilleas Mantzios - cloud
> <[email protected]> wrote:
>
> Good Day Vladimir
>
> On 9/27/23 09:03, Vladimir Sitnikov wrote:
> >> so there was the option to change this to false and recompile
> > We try doing our best to keep backward compatibility both
> > compilation-wise and behaviour-wise.
> > However, we treat "private fields and methods" as private, and we do
> > not expect people would depend on them.
> > If you have to modify sources or depend on private APIs I would
> > suggest raising an issue or PR so it could be incorporated
> > into the driver itself.
> >
> > Would you please provide a test case of what you are doing with
> PgArray?
> > What is exactly the sequence of JDBC calls, the actual and the
> > expected outcomes in your case?
>
> E.g. for the case of floats, we have to change all:
>
> java.sql.Array arr = rs.getArray(1);
>
> Object objarr = arr.getArray();
>
> float flarr[] = (float[]) objarr;
>
> to
>
> java.sql.Array arr = rs.getArray(1);
>
> Object objarr = arr.getArray();
>
> Float flarr[] = (Float[]) objarr;
>
>
>
> So the problem with using float instead of Float is that it is
> impossible to have a null float and arrays can have nulls.
Thanks Dave, we wrote much of the code before 2008, and we had to
implement our own version of nulls in arrays of primitives. So this code
was stuck everywhere. Plus we got like 120+ remote sites (slaves) (
which run ... even older code) so we must fully support them as well.
Its only about 200 source files in the central system's repo, so we will
have to do it sooner or later.
The hard part would be migrating from pgsql 10 to 16.
>
> Dave
>
>
> >
> > The mentioned "useObjects" has been removed in
> > https://github.com/pgjdbc/pgjdbc/pull/1194 (Refactor decoding
> arrays)
> >
> > Vladimir
>
>
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: Regarding useObjects
@ 2023-09-27 10:07 Achilleas Mantzios - cloud <[email protected]>
parent: Vladimir Sitnikov <[email protected]>
0 siblings, 1 reply; 14+ messages in thread
From: Achilleas Mantzios - cloud @ 2023-09-27 10:07 UTC (permalink / raw)
To: Vladimir Sitnikov <[email protected]>; Dave Cramer <[email protected]>; +Cc: pgsql-jdbc
On 9/27/23 12:55, Vladimir Sitnikov wrote:
> > So the problem with using float instead of Float is that it is
> impossible to have a null float and arrays can have nulls.
>
> There's a feature request for retrieving primitive arrays:
> https://github.com/pgjdbc/pgjdbc/issues/2939
back in pre-postgresql-42* dayswe used to use -888 and -888.888 to
represent int NULL and float NULL respectively, quite ...primitive but
it worked. We should retain this old mapping , but once all systems are
up to date we will start storing and reading NULLs in arrays as NULLs.
>
> Vladimir
>
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: Regarding useObjects
@ 2023-09-27 10:17 Dave Cramer <[email protected]>
parent: Achilleas Mantzios - cloud <[email protected]>
0 siblings, 2 replies; 14+ messages in thread
From: Dave Cramer @ 2023-09-27 10:17 UTC (permalink / raw)
To: Achilleas Mantzios - cloud <[email protected]>; +Cc: Vladimir Sitnikov <[email protected]>; pgsql-jdbc
On Wed, 27 Sept 2023 at 06:07, Achilleas Mantzios - cloud <
[email protected]> wrote:
>
> On 9/27/23 12:55, Vladimir Sitnikov wrote:
>
> > So the problem with using float instead of Float is that it is
> impossible to have a null float and arrays can have nulls.
>
> There's a feature request for retrieving primitive arrays:
> https://github.com/pgjdbc/pgjdbc/issues/2939
>
> back in pre-postgresql-42* days we used to use -888 and -888.888 to
> represent int NULL and float NULL respectively, quite ...primitive but it
> worked. We should retain this old mapping , but once all systems are up to
> date we will start storing and reading NULLs in arrays as NULLs.
>
Using that mapping is not something that we would entertain.
If you are going to actually store NULL in the array, how would that work
with primitives ?
Dave
>
> Vladimir
>
>
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: Regarding useObjects
@ 2023-09-27 10:28 Achilleas Mantzios - cloud <[email protected]>
parent: Dave Cramer <[email protected]>
1 sibling, 1 reply; 14+ messages in thread
From: Achilleas Mantzios - cloud @ 2023-09-27 10:28 UTC (permalink / raw)
To: Dave Cramer <[email protected]>; +Cc: Vladimir Sitnikov <[email protected]>; pgsql-jdbc
On 9/27/23 13:17, Dave Cramer wrote:
>
>
> On Wed, 27 Sept 2023 at 06:07, Achilleas Mantzios - cloud
> <[email protected]> wrote:
>
>
> On 9/27/23 12:55, Vladimir Sitnikov wrote:
>> > So the problem with using float instead of Float is that it is
>> impossible to have a null float and arrays can have nulls.
>>
>> There's a feature request for retrieving primitive arrays:
>> https://github.com/pgjdbc/pgjdbc/issues/2939
>
> back in pre-postgresql-42* dayswe used to use -888 and -888.888 to
> represent int NULL and float NULL respectively, quite ...primitive
> but it worked. We should retain this old mapping , but once all
> systems are up to date we will start storing and reading NULLs in
> arrays as NULLs.
>
> Using that mapping is not something that we would entertain.
>
> If you are going to actually store NULL in the array, how would that
> work with primitives ?
We support our central system (master) plus 120 slave systems
communicating via satellites (running very old versions of everything ,
linux, postgersql , java, jdbc, etc) using custom replication code (a
hack of DBmirror) that we wrote back in 2003 or so. Data come back and
forth, so we have to support all those 120 archaic slaves while we
upgrade and after we upgrade the central system.
When everything is up to date, (which will be some years from now), then
we will start actually storing NULLs inside arrays instead of -888 and
-888.888 . BUT even then, we are not willing to update the actual old
data (-888) to the new NULL version, because that would trigger a
massive replication traffic from our central system to the slaves. Also
updating all past / historic values would cause bloating, huge
autovacuum activity, among other things on those remote slaves that run
unmanned (in simple english : I am the only DBA for all 1 + 120
postgresql instances) . So we should support historic data as they are,
until something bigger happens (like a vast update in our
topology/logic/etc).
>
> Dave
>
>>
>> Vladimir
>>
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: Regarding useObjects
@ 2023-09-27 10:39 Dave Cramer <[email protected]>
parent: Achilleas Mantzios - cloud <[email protected]>
0 siblings, 1 reply; 14+ messages in thread
From: Dave Cramer @ 2023-09-27 10:39 UTC (permalink / raw)
To: Achilleas Mantzios - cloud <[email protected]>; +Cc: Vladimir Sitnikov <[email protected]>; pgsql-jdbc
On Wed, 27 Sept 2023 at 06:28, Achilleas Mantzios - cloud <
[email protected]> wrote:
>
> On 9/27/23 13:17, Dave Cramer wrote:
>
>
>
> On Wed, 27 Sept 2023 at 06:07, Achilleas Mantzios - cloud <
> [email protected]> wrote:
>
>>
>> On 9/27/23 12:55, Vladimir Sitnikov wrote:
>>
>> > So the problem with using float instead of Float is that it is
>> impossible to have a null float and arrays can have nulls.
>>
>> There's a feature request for retrieving primitive arrays:
>> https://github.com/pgjdbc/pgjdbc/issues/2939
>>
>> back in pre-postgresql-42* days we used to use -888 and -888.888 to
>> represent int NULL and float NULL respectively, quite ...primitive but it
>> worked. We should retain this old mapping , but once all systems are up to
>> date we will start storing and reading NULLs in arrays as NULLs.
>>
> Using that mapping is not something that we would entertain.
>
> If you are going to actually store NULL in the array, how would that work
> with primitives ?
>
> We support our central system (master) plus 120 slave systems
> communicating via satellites (running very old versions of everything ,
> linux, postgersql , java, jdbc, etc) using custom replication code (a hack
> of DBmirror) that we wrote back in 2003 or so. Data come back and forth, so
> we have to support all those 120 archaic slaves while we upgrade and after
> we upgrade the central system.
>
> When everything is up to date, (which will be some years from now), then
> we will start actually storing NULLs inside arrays instead of -888 and
> -888.888 . BUT even then, we are not willing to update the actual old data
> (-888) to the new NULL version, because that would trigger a massive
> replication traffic from our central system to the slaves. Also updating
> all past / historic values would cause bloating, huge autovacuum activity,
> among other things on those remote slaves that run unmanned (in simple
> english : I am the only DBA for all 1 + 120 postgresql instances) . So we
> should support historic data as they are, until something bigger happens
> (like a vast update in our topology/logic/etc).
>
So it sounds like this would work for you if someone implemented primitive
arrays.
Dave
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: Regarding useObjects
@ 2023-09-27 11:11 Achilleas Mantzios - cloud <[email protected]>
parent: Dave Cramer <[email protected]>
0 siblings, 0 replies; 14+ messages in thread
From: Achilleas Mantzios - cloud @ 2023-09-27 11:11 UTC (permalink / raw)
To: Dave Cramer <[email protected]>; +Cc: Vladimir Sitnikov <[email protected]>; pgsql-jdbc
On 9/27/23 13:39, Dave Cramer wrote:
>
>
> On Wed, 27 Sept 2023 at 06:28, Achilleas Mantzios - cloud
> <[email protected]> wrote:
>
>
> On 9/27/23 13:17, Dave Cramer wrote:
>>
>>
>> On Wed, 27 Sept 2023 at 06:07, Achilleas Mantzios - cloud
>> <[email protected]> wrote:
>>
>>
>> On 9/27/23 12:55, Vladimir Sitnikov wrote:
>>> > So the problem with using float instead of Float is that
>>> it is impossible to have a null float and arrays can have nulls.
>>>
>>> There's a feature request for retrieving primitive arrays:
>>> https://github.com/pgjdbc/pgjdbc/issues/2939
>>
>> back in pre-postgresql-42* dayswe used to use -888 and
>> -888.888 to represent int NULL and float NULL respectively,
>> quite ...primitive but it worked. We should retain this old
>> mapping , but once all systems are up to date we will start
>> storing and reading NULLs in arrays as NULLs.
>>
>> Using that mapping is not something that we would entertain.
>>
>> If you are going to actually store NULL in the array, how would
>> that work with primitives ?
>
> We support our central system (master) plus 120 slave systems
> communicating via satellites (running very old versions of
> everything , linux, postgersql , java, jdbc, etc) using custom
> replication code (a hack of DBmirror) that we wrote back in 2003
> or so. Data come back and forth, so we have to support all those
> 120 archaic slaves while we upgrade and after we upgrade the
> central system.
>
> When everything is up to date, (which will be some years from
> now), then we will start actually storing NULLs inside arrays
> instead of -888 and -888.888 . BUT even then, we are not willing
> to update the actual old data (-888) to the new NULL version,
> because that would trigger a massive replication traffic from our
> central system to the slaves. Also updating all past / historic
> values would cause bloating, huge autovacuum activity, among other
> things on those remote slaves that run unmanned (in simple english
> : I am the only DBA for all 1 + 120 postgresql instances) . So we
> should support historic data as they are, until something bigger
> happens (like a vast update in our topology/logic/etc).
>
>
> So it sounds like this would work for you if someone implemented
> primitive arrays.
Yes or we could just upgrade JDBC driver in the central system, and
touch those ~ 200 source files to just work (not throw exception), but
still retaining the -888 representation.
But an implementation of primitive arrays for ints,longs,floats,doubles
would be better at this stage.
>
> Dave
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: Regarding useObjects
@ 2023-10-04 17:45 DB Kho <[email protected]>
parent: Dave Cramer <[email protected]>
1 sibling, 0 replies; 14+ messages in thread
From: DB Kho @ 2023-10-04 17:45 UTC (permalink / raw)
To: [email protected] <[email protected]>; +Cc: pgsql-jdbc
<!doctype html>
<html>
<head>
<meta charset="UTF-8">
</head>
<body>
<div>
Unsubscribe
</div>
<div class="default-style">
<br>
</div>
<blockquote type="cite">
<div>
Op 27-09-2023 12:17 schreef Dave Cramer <[email protected]>:
</div>
<div>
<br>
</div>
<div>
<br>
</div>
<div dir="ltr">
<div dir="ltr">
<br>
</div>
<br>
<div class="gmail_quote">
<div class="gmail_attr" dir="ltr">
On Wed, 27 Sept 2023 at 06:07, Achilleas Mantzios - cloud <<a href="mailto:[email protected]">[email protected]</a>> wrote:
<br>
</div>
<blockquote>
<div>
<p><br></p>
<div>
On 9/27/23 12:55, Vladimir Sitnikov wrote:
<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>
> So the problem with using float instead of Float is that it is impossible to have a null float and arrays can have nulls.
<br>
</div>
<div>
<br>
</div>There's a feature request for retrieving primitive arrays: <a target="_blank" href="https://github.com/pgjdbc/pgjdbc/issues/2939"; rel="noopener">https://github.com/pgjdbc/pgjdbc/issues/2939</a;
<br>
</div>
</blockquote>
<p>back in pre-<span style="font-family: monospace;"><span style="color: #000000; background-color: #ffffff;">postgresql-42* </span></span>days we used to use -888 and -888.888 to represent int NULL and float NULL respectively, quite ...primitive but it worked. We should retain this old mapping , but once all systems are up to date we will start storing and reading NULLs in arrays as NULLs.<br></p>
</div>
</blockquote>
<div>
Using that mapping is not something that we would entertain.
</div>
<div>
<br>
</div>
<div>
If you are going to actually store NULL in the array, how would that work with primitives ?
</div>
<div>
<br>
</div>
<div>
Dave
</div>
<blockquote>
<div>
<p><br></p>
<blockquote type="cite">
<div dir="ltr">
<br>Vladimir
<br>
<br>
</div>
</blockquote>
</div>
</blockquote>
</div>
</div>
</blockquote>
</body>
</html>
^ permalink raw reply [nested|flat] 14+ messages in thread
end of thread, other threads:[~2023-10-04 17:45 UTC | newest]
Thread overview: 14+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2023-09-26 15:38 Regarding useObjects Achilleas Mantzios - cloud <[email protected]>
2023-09-26 16:07 ` Vladimir Sitnikov <[email protected]>
2023-09-26 16:58 ` Achilleas Mantzios <[email protected]>
2023-09-27 06:03 ` Vladimir Sitnikov <[email protected]>
2023-09-27 08:59 ` Achilleas Mantzios - cloud <[email protected]>
2023-09-27 09:44 ` Dave Cramer <[email protected]>
2023-09-27 09:55 ` Vladimir Sitnikov <[email protected]>
2023-09-27 10:07 ` Achilleas Mantzios - cloud <[email protected]>
2023-09-27 10:17 ` Dave Cramer <[email protected]>
2023-09-27 10:28 ` Achilleas Mantzios - cloud <[email protected]>
2023-09-27 10:39 ` Dave Cramer <[email protected]>
2023-09-27 11:11 ` Achilleas Mantzios - cloud <[email protected]>
2023-10-04 17:45 ` DB Kho <[email protected]>
2023-09-27 10:00 ` Achilleas Mantzios - cloud <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox