-
Notifications
You must be signed in to change notification settings - Fork 137
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
Home server database #39
Comments
Submitted by SourceForge user rocketman768 on 2012-08-05 17:00:51 UTC. +1 schappenberg. Just make a GUI option for the location of recipes.db. For syncing, I just made a symbolic link from ~/.gourmet/recipes.db to my Dropbox folder. |
Submitted by SourceForge user enfant_terrible on 2012-02-05 01:27:20 UTC. Good to hear about posgres working! As the Windows part is off-topic, please refer to this forum thread I've just created: |
Submitted by SourceForge user indymaynard on 2012-02-04 23:26:52 UTC. Well, after installing python-psycopg2, it seems to work fine. I did run into a problem with the nutritional values, but after closing and restarting, it seemed to work. However, I would love to know if anyone could tell me:
|
Submitted by SourceForge user indymaynard on 2012-02-04 22:27:19 UTC. I can tell you that MySQL didn't work even after the manual database alteration. The error returned after that was: sqlalchemy.exc.InvalidRequestError: VARCHAR requires a length when rendered on MySQL Fedora always forgets my postgres stuff, so I have to reconfigure before I try. I really want to get this working... |
Submitted by SourceForge user enfant_terrible on 2012-02-04 21:57:59 UTC. I haven't tried postgres yet. If you do, please comment here on the result! |
Submitted by SourceForge user indymaynard on 2012-02-04 21:36:34 UTC. When you say "some backends," does that include postgres? I have yet to try that. |
Submitted by SourceForge user enfant_terrible on 2012-01-30 19:02:32 UTC. I've also tried it out. The problem is that some backends (like MySQL) are "pickier" than others (like SQLite). If you don't want to wait, you might want to try to modify the database layout manually, as described in this blog post: |
Submitted by SourceForge user indymaynard on 2012-01-30 03:27:21 UTC. Sadly, the suggested --database-url command does not work. In my particular case, that gives me this error: sqlalchemy.exc.OperationalError: (OperationalError) (1170, "BLOB/TEXT column 'ingkey' used in key specification without a key length") '\nCREATE TABLE shopcats (\n\tingkey TEXT NOT NULL, \n\tshopcategory TEXT, \n\tposition INTEGER, \n\tPRIMARY KEY (ingkey)\n)\n\n' () I am not a python programmer, nor do I suspect that I will learn it anytime soon, but I messed with the source code a little a year or so back. Whenever I "fixed" one problem, another popped up. It seems as though SQLAlchemy doesn't make it as seamless as I thought it would. I would love this feature! I have a whole family that is interested in this! |
Submitted by SourceForge user enfant_terrible on 2012-01-15 17:29:27 UTC. @schappenberg: you can already change the location of recipes.db, using the --gourmetdir command line option. as for server-based database storage, gourmet uses SQLAlchemy -- by default to access a SQLite database, but using the --database-url command line option, you might also succeed using e.g. a MySQL db instead. |
Submitted by SourceForge user schappenberg on 2011-12-30 04:57:04 UTC. i'll give that a +1 |
Converted from SourceForge issue 3396654, submitted by SourceForge user nobody on 2011-08-22 22:37:16 UTC.
In my home I keep an inventory system in my pantry and a touch screen in my kitchen both connected to a server. It would be nice to have both access the same recipe database on the server. Gourmet would be installed on all systems but only access one recipe database on the server. Adding a recipe on one system would be accessed by all. Also I would be able to generate shopping list from any system and later access, update or print from any of the other systems.
The text was updated successfully, but these errors were encountered: