question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Postgres synchronisation unnecessarily drops column with data type "float"

See original GitHub issue

Issue type:

[ ] question [x] bug report [ ] feature request [ ] documentation issue

Database system/driver:

[ ] cordova [ ] mongodb [ ] mssql [ ] mysql / mariadb [ ] oracle [x] postgres [ ] sqlite [ ] sqljs [ ] react-native

TypeORM version:

[ ] latest [ ] @next [x] 0.2.5 Postgres v10

Steps to reproduce or a small repository showing the problem:

Create an Entity with a column of data type float:

@Entity()
export class FloatTest{

  @PrimaryColumn()
  id: number

  @Column('float')
  some_num: number
}

Add some data to the table:

const con = await createConnection({
    ...,
    synchronize: true,
    logging: true
  })
await con.manager.save(FloatTest, { id: 0, sum_num: 10.51 })

On the initial run this all works fine – run it again however and you’ll get an error like the following: column "some_num" contains null values. With logging enabled the “sum_num” column is clearly being dropped and rebuilt.

I think this error is due to Postgres using double precision as float internally(see https://www.postgresql.org/docs/10/static/datatype-numeric.html section 8.1.3). This seems to be the case when the column check SQL is run: SELECT *, "udt_name"::"regtype" AS "regtype" FROM "information_schema"."columns".... The “regtype” for the float data type returns double precision.

The solution, I think is to add an additional check in the normalizeType function in PostgresDriver.ts like so:

else if (column.type === "float") {
   return "double precision";
}

Thanks for the great ORM!

Issue Analytics

  • State:closed
  • Created 5 years ago
  • Reactions:8
  • Comments:10 (4 by maintainers)

github_iconTop GitHub Comments

3reactions
Alex0007commented, Aug 13, 2018

Confirming this bug on typeorm@next version

2reactions
mattb-prgcommented, Jun 18, 2018

@serranoarevalo Yep, just use the double precision type instead of float when defining your column. Or modify the source to add the extra conditional statement(see the very end of my original post)

Read more comments on GitHub >

github_iconTop Results From Across the Web

Documentation: 7.4: Data Types - PostgreSQL
Here, p specifies the minimum acceptable precision in binary digits. PostgreSQL accepts float(1) to float(24) as selecting the real type, while float(25) to ......
Read more >
PostgreSQL | Database to Data Warehouse | Fivetran setup
All rows are gone. Drop database, N/A, There is nothing left to sync. Change existing column's data type, Yes, This updates every single ......
Read more >
Basic Normalization | Airbyte Documentation
If an unmodified version of the data exists in the destination, it can be retransformed without needing to sync data again. If you...
Read more >
PostgreSQL Sync Replication: 3 Easy Methods - Hevo Data
In addition to being open-source, it is highly extensible as it allows you to define your data types, develop your own custom functions...
Read more >
Postgres Release Notes - All Versions - Bucardo
Add MIN() and MAX() aggregates for the xid8 data type (Ken Kato) ... DROP NOT NULL for a column that is part of...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found