Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Creating wrong record #20

Open
stebogit opened this issue Nov 25, 2017 · 3 comments
Open

Creating wrong record #20

stebogit opened this issue Nov 25, 2017 · 3 comments

Comments

@stebogit
Copy link

stebogit commented Nov 25, 2017

Hi,
I noticed that in some particular cases the insertOnDuplicateKey method creates a wrong record in the table. This is an example of input with the table schema, at the very bottom.
Simply inserting the data, starting from an empty table,

AwnRecord::insertOnDuplicateKey($records);

results in the insertion of only 50 records (out of 92 as input) one of which is totally wrong and even invalid, i.e. the is_valid_solarRad field, defined as boolean, is equal to 127 and tstamp, a datetime field, equals 0000-00-00 00:00:00 (which I believe it's not a valid datetime value)

screen shot 2017-11-25 at 1 17 06 am

What's wrong with the code/data?
How can the database even allow for creating an invalid type field?
If of any relevance, I noticed the not inserted records are mostly empty, although null is a valid value for those columns (and relevant data in my case).

@yadakhov
Copy link
Owner

How many unique index is on the table?

The only way I think I can fix the issue if I can replicate it.

Do you have a simple example of a table schema and data to insert.

@stebogit
Copy link
Author

stebogit commented Nov 27, 2017

Sorry @yadakhov I linked the gist but it was probably not really visible. Here you can fine both data and the table schema that in my case generates the issue: https://gist.github.com/stebogit/5b9f2a7cf31ad468ece4bada2c85f91a

The PK is the combination of station_id and tstamp:
PRIMARY KEY (station_id, tstamp)

@yadakhov
Copy link
Owner

I'll take a look when I got some free time.

I'm suspecting it's the composite primary key. PRIMARY KEY (station_id, tstamp)

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

No branches or pull requests

2 participants