double is getting cast as string or something

[kevinelliott]

Recently updated to latest, and now doubles are not correctly going into Postgres.

Ingest(jaero-c-adsc): [FINE] - SBSParser.parseMSG:   Coordinates   : 33.482723, -122.560215

These are showing correctly as double objects in dart, but then when the query executes:

Ingest(jaero-c-adsc): [DEBUG] - [aero-adsc] Message will have latitude: 33.482723
Ingest(jaero-c-adsc): [DEBUG] - [aero-adsc] Message will have longitude: -122.560215
Ingest(jaero-c-adsc): [ERROR] - [aero-adsc] Unexpected error trying to insert message (PostgreSQLSeverity.error 22P02: invalid input syntax for type double precision: "null" )
#0      MessageManager.create (package:aggregation_server/orm/managers/message_manager.dart:121)
<asynchronous suspension>
#1      SBSMessageImporter.insertOrSkipMessage (package:aggregation_server/apps/aggregation_server/importers/sbs_message_importer.dart:179)
<asynchronous suspension>
#2      JaeroADSCProcessor.process (package:aggregation_server/apps/aggregation_server/processors/jaero_adsc_processor.dart:47)
<asynchronous suspension>

They are all native doubles, and in the database it is double precision.

In the generated file, I see:

  @override
  Map<String, String> get casts {
    return {'frequency': 'char', 'latitude': 'char', 'longitude': 'char'};
  }

Which tells me the doubles are being cast during execution. They should be cast to double precision. Or likely, not cast at all.

[kevinelliott]

2022-09-24 22:05:11.473 UTC [3571191] STATEMENT: WITH messages as (INSERT INTO messages (timestamp, source_type, source, link_direction, from_hex, to_hex, frequency, level, error, mode, label, block_id, ack, tail, flight, message_number, text, departing_airport, destination_airport, block_end, station_id, airframe_id, flight_id, latitude, longitude, altitude) VALUES ($1, $2, $3, $4, $5, $6, CAST ($7 as double precision), $8, $9, $10, $11, $12, $13, $14, $15, $16, $17, $18, $19, $20, $21, $22, $23, CAST ($24 as double precision), CAST ($25 as double precision), $26) RETURNING messages.id, messages.created_at, messages.updated_at, messages.timestamp, messages.station_id, messages.airframe_id, messages.flight_id, messages.source, messages.source_type, messages.link_direction, messages.from_hex, messages.to_hex, messages.channel, messages.frequency, messages.level, messages.error, messages.mode, messages.label, messages.block_id, messages.ack, messages.tail, messages.flight, messages.message_number, messages.data, messages.text, messages.departing_airport, messages.destination_airport, messages.latitude, messages.longitude, messages.altitude, messages.block_end) SELECT id, created_at, updated_at, timestamp, station_id, airframe_id, flight_id, source, source_type, link_direction, from_hex, to_hex, channel, CAST (frequency AS char), level, error, mode, label, block_id, ack, tail, flight, message_number, data, text, departing_airport, destination_airport, CAST (latitude AS char), CAST (longitude AS char), altitude, block_end FROM messages

[kevinelliott]

This appears to be the source of the issue... https://github.com/dukefirehawk/angel/blob/master/packages/orm/angel_orm_generator/lib/src/orm_generator.dart#L114

[kevinelliott]

There are other areas in the generated files where it's doing a double --> string --> double unnecessarily. And then of course the conversion to string and back causes it to be null for some reason, and then Postgres complains about it.

[kevinelliott]

If I remove the conversions between double and string throughout the generated, things work! double --> database direct, rather than the intermediary conversions.

Can you please adjust to not do the intermediary for double?

[dukefirehawk]

Looks like the existing test cases do not cover this. Will resolve this issue as high priority and add a test case for it.

[dukefirehawk]

double --> string --> double casting has been removed in angel_orm_generator 7.0.1. All the numeric fields now goes directly to the database. Thanks for reporting this bug as the casting is in the code since version 4. This changes should improve the performance. Let me know if it works for you.

[kevinelliott]

This seems to have been resolved, thank you @dukefirehawk