Support postgres DBs in tt-rss #37
Comments
ghost
assigned 
|
I would like this with Google reader shutting down in July getting this data into postgresql would be nice. |
|
Well have you tried it on postgres yet? I didn't ever, so it might very well be that the import actually works on postgres as-is. As far as I can tell, the SQL code I generate is not fancy on any way (well it uses sub selects, but postgres has them, too). I'd suggest you backup your database (or use a copy for testing) and give it a try... salyavin [email protected] schrieb:
|
|
When I try it I get a lot of invalid commands |
|
I really can't say if this is a problem that has to do with postgres or with the fact that my tool doesn't handle Japanese correctly (or that something went wrong on your end). The fact that I can't read Japanese doesn't help :) I mean, the end result should be valid utf-8, but without understanding postgres complaints, I don't know what to do. Cab you shed light on them? salyavin [email protected] schrieb:
|
|
Well, the most probable explanation is that the sub SELECT statement is giving postgres trouble (a syntax error). Still not sure. I don't have a postgres database with tt-rss installed nor time to get one. Would you be willing to import a test snippet from my starred items (say, one or two articles) to see if the problem is independent of japanese? |
|
Sure. I would be happy to. |
|
okay, I think I can send you something tonight (it's 11:45am where I am, as a reference). ----- Original Message -----
|
|
ERROR: 時間帯の置換が範囲外です: "2007-07-30 00-23-16" I am seeing errors like replacement date out of range and published row is a boolean when it should be an integer |
|
Here we go |
|
Thanks. So maybe postgres wants a different kind of date format than MySQL. I used '%Y-%m-%d %H-%M-%S',but postgres probably wants the time separated with colons, not with dashes (e.g. see Section 8.5.1.3), so I should use '%Y-%m-%d %H:%M:%S', but I'm still just guessing bcs I have limited time. And in MySQL I use the published flag as 0 or 1 (by casting the Python boolean), but Postgres wants a boolean expression (I think postgres uses true and false). I think I can push out a version of the script tonight that would treat these two things differently when it's a postgres database. Then we can see how far that got us. Thanks for standing by :) |
|
Thanks a bunch, you are sure trying quickly. It is 8:20PM in here Japan, I will probably be able to try it later in the morning. |
|
I found a lot of issues with postgres. I managed to fix a few but it still doesn't quite work. I'll submit a pull req if I get it working completely. Added: I didn't see the later comments. The first problem I found is the multi-line inserts don't track 's properly, and (as mentioned above) true/false vs 0/1. |
|
Awesome! Then I'll hold back my blind flight efforts for now. Dis McCarthy [email protected] schrieb:
|
|
I accepted a pull request (see above) by @tafryn which makes the MySQL/Postgres distinction nicely. What still could be done is to
|
|
I'd like to hear from Postgres users if they are successful with this, as I didn't test it myself. |
|
This appeared to work perfectly for me, thank you very much! |
|
Wow, that was fast, thanks. Hey guys, someone successfully imported freaking Japanese articles into Postgres. Woohoo :) |
The inserting code currently only speaks to MySQL databases.
We have MySQL-specific code that sets the charset to be utf-8 and that gets the last inserted ID. For postgres, we would need equivalents.
Also, we would need a new option in the config file to select MySQL or postgres.
The text was updated successfully, but these errors were encountered: