Skip to content

Fix float64 oracle overflow#4

Open
misterEggroll wants to merge 13 commits intomisterEggroll:masterfrom
skit-ai:fix-float64-oracle-overflow
Open

Fix float64 oracle overflow#4
misterEggroll wants to merge 13 commits intomisterEggroll:masterfrom
skit-ai:fix-float64-oracle-overflow

Conversation

@misterEggroll
Copy link
Owner

  • The oracle driver returns float64 when the no. of rows goes beyond 1000000.
  • When using gorm.Model, this results in an error when reading from a table with this many rows.
  • Introducing gorm.ORM which will mitigate this issue and work for all databases by adapting the driver results.
  • This is achieved by implementing the sql.Scanner interface from the database/sql package.
  • The ID is encapsulated as a uint in the primary struct.

akshaydeshraj and others added 13 commits August 16, 2019 16:17
add: Fn to remove constraint from a table
…limit

add: Fn to determine dialect-specific byte insertion limit
* If records go beyond 1000000, the ID returned by the oracle driver is of type float64 instead of uint(uint64)
* To mitigate this issue, introducing the `primary` struct
* The `primary` struct implements the `Scanner` interface to convert float64 and int64 into a unit ID
* The `primary` struct implements the `Valuer` interface to return the uint value of the ID it encapsulates
* Introducing the `ORM` struct which makes use of the `primary` struct to encapsulate the ID returned by the DB
* This is to mitigate the scenario where the reference to the rowid of the oracle entry is returned as an int64.
* This int64 is converted to uint internally by the Scan() implementation of the `primary` struct
* Hence, we need to access that converted value by checking if the primary field is of type `primary`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants