systematic failure when writing a dataframe of 1 column of integer. this should solve issue Issue #3628
State: closed

...lite ( Issue #3628 )

A push of a dataframe of one column of integers fail ungraciously, because sqlite doesn't recognize well the data type.
This should solve the problem by converting back to normal types


Labels:

Comments:
can you add a test for this, and a release notes mention? thxs

fyi..if this is ONLY breaking on py3....you can do: `if py3compat.PY3`

(or even better is the make the adjustment in the code and have a test that covers all py)

if gives a bogus result in python 3, and fails on python 2.7, as noticed cpcloud, so it's a fix for both

pls add the issue at the top of the test

eg GH???? as a comment

a nice way of testing things like this is to test a round trip

df = create df
write_frame
result = read_frame
assert_frame_equal(df,result)

@stonebig should this be closed in favor of #3644?

Hello @jreback 

Yes : #3644 is exactly #3628 after reading the CONTRIBUTING and git documentation.

CONTRIBUTING is speaking of "rebase", but in my newcomer case I found  "git reset" to be more fit. 

Maybe would it be helpfull for your next newcomer to include a few more lines/links on "how to transform a working_patch in a working_PR" ? 

Maybe there is a nice résumé-on-a-page somewhere already, but it's hard to find it as a newcomer.

 # the procedure I figured out for my particular case  
.....0 - remember next time it's better to not touch your MASTER branch of the forked project, work only on branches 
.... 1 - connect TRAVIS CI to your github account
.... 2 - commit a patch on your "my_working_patch" branch to test Travis, until it works

then, to rewrite history of your "my_working_patch" patch from current pandas master commit
.... 3 - read CONTRIBUTING and previous commits on pydata/pandas to understand what it means.
.... 4 - do the following until success (expect 3 hepic fails, so keep untouched your "my_working_patch")  
git remote add pandas_upstream "https://github.com/pydata/pandas.git"
git fetch pandas_upstream
git checkout "my_working_patch"
git branch "my_working_PR"
git merge pandas_upstream/master 
   (resolve manually non-automatic merge issues  ... (purchase a book on "git" here, or iron your shirts while looking at youtube tutorials) ...)
... check you are on your "my_working_PR" before doing the next "git reset" command, and all will be fine and safe
git reset  83a6e0...51f18cea (the sha of the last commit you see on the official pydata/pandas MASTER branch)
   ... then , file by file, include the test creation part 
git diff (show you the files to contributes, so you know the "git add" to do)
git add pandas/io/tests/test_sql.py  (for example)
git commit  -m "TST: blabla test issue xxx"
git branch "my_working_PR_test_only" 
  ... that branch will be automatically tested by Travis, and should fail to demonstrate the issue
  ... then, file by file, include the bug solving part
git diff (show you the remaining files to contributes, so you know the "git add" to do next)
git add pandas/io/sql.py  (for example again)
git commit  -m "BUG : blabla solve issue xxx"

... 5 - do your PR  when 
the Travis "my_working_PR_test_only"  is red 
the Travis "my_working_PR" is green
looking at your commits, you don't feel totally ashame in regards to CONTRIBUTING.
check you are on the "my_working_PR" branch when you click the upper right "Pull Request" button

i guess there isnt a link in contributing to here: http://pandas.pydata.org/developers.html

I'll show u how to rebase in a bit

Here is my usual workflow:

Start in master & make sure master it up 2 date

```
git checkout master
git pull
```

Create a new branch that tracks master (and switch to it)

```
git checkout -b patch_branch --track master
```

Edit/test and commit (repeat this as needed)

```
git commit -a
```

```
git push myfork patch_branch
```

To update to master

```
git checkout master
git pull
git checkout patch_branch
git pull --rebase
```

then fix issues, add, and `git rebase --continue`

edit/patch some more (like above)

To rebase/e.g. squash commits together

```
git checkout patch_branch
git rebase -i <commit_before_my_branch>
```

use `s` to squash commits together

This _replaces_ the commits on the branch iwth your new set ( rather than just appending)

```
git push myfork patch_branch -f
```

closing in favor of #3644

This procedure looks much much simpler, I'll apply it now.

I already used the first part to get my 'master' back like the official one 

git checkout master
git pull pandas_upstream master
git push origin master   (I guess this is a detail not to forget)
(then to put back my master like the official one, I point its head to the last official commit)
git reset 3bf8269e35611cd8797d3f5df939bba624d88c3c
git push origin master -f 

\o// , I feel much much better now. 

Thank you very much for the procedure !