Re: 3rd party client applications accessing pylons model over a local network
What do you mean when you say importing a slightly modifed model on each
client machine? How different is it and why?
I had to change the binding in the model file, so originally it read:
Session = scoped_session(sessionmaker(autoflush=True, transactional=True,
bind=config['pylons.app_globals'].sa_engine))
Now it reads:
engine = create_engine('sqlite:///C:/ark/data/project.db')
Session = scoped_session(sessionmaker(autoflush=True, transactional=True,
bind=engine))
(I'm testing the database on a local drive atm).
I'll look into using MySQL, the idea of transferring db's terrifies me
somewhat, but I'm sure I'll get there :).
Jules
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com
To unsubscribe from this group, send email to
pylons-discuss+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---
Re: 3rd party client applications accessing pylons model over a local network
On Fri, Sep 11, 2009 at 12:04 AM, Jules Stevenson
droolz...@googlemail.com wrote:
What do you mean when you say importing a slightly modifed model on each
client machine? How different is it and why?
I had to change the binding in the model file, so originally it read:
Session = scoped_session(sessionmaker(autoflush=True, transactional=True,
bind=config['pylons.app_globals'].sa_engine))
Now it reads:
engine = create_engine('sqlite:///C:/ark/data/project.db')
Session = scoped_session(sessionmaker(autoflush=True, transactional=True,
bind=engine))
(I'm testing the database on a local drive atm).
I'll look into using MySQL, the idea of transferring db's terrifies me
somewhat, but I'm sure I'll get there :).
The main differences I've seen with MySQL compared to SQLite off the
top of my head are:
- Rigid column lengths (SQLite stores long values; MySQL truncates
them with a warning)
- Different date handling functions (you'll need if-blocks in your
code; e.g., if engine.name==mysql)
- Different autoincrement policy (not really an issue)
- String comparisons are case insensitive (though I think SQLite's
LIKE is case-insensitive)
--
Mike Orr sluggos...@gmail.com
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com
To unsubscribe from this group, send email to
pylons-discuss+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---
Re: 3rd party client applications accessing pylons model over a local network
The main differences I've seen with MySQL compared to SQLite off the top of my head are: - Rigid column lengths (SQLite stores long values; MySQL truncates them with a warning) - Different date handling functions (you'll need if-blocks in your code; e.g., if engine.name==mysql) - Different autoincrement policy (not really an issue) - String comparisons are case insensitive (though I think SQLite's LIKE is case-insensitive) Thanks Mike, much appreciated. I've found the rigid column lengths one, but so far so good the models been recreated in MySQL with a few minor tweaks, and I've been able to import the dumped data from SQlite, so wasn't as painful as I was expecting. Thanks very much for yours and everyone else's input --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: 3rd party client applications accessing pylons model over a local network
On Fri, Sep 11, 2009 at 7:54 AM, Jules Stevenson droolz...@googlemail.com wrote: The main differences I've seen with MySQL compared to SQLite off the top of my head are: - Rigid column lengths (SQLite stores long values; MySQL truncates them with a warning) - Different date handling functions (you'll need if-blocks in your code; e.g., if engine.name==mysql) - Different autoincrement policy (not really an issue) - String comparisons are case insensitive (though I think SQLite's LIKE is case-insensitive) Thanks Mike, much appreciated. I've found the rigid column lengths one, That was one reason I gave up on MySQL for one site. The incoming data is not interactive but imported from several sources. I have no control over the lengths of these, so I didn't want the importer blowing up after I'm gone on any values that unexpectedly become longer than 255 or 65535 characters. MySQL has VARCHAR, TEXT, MEDIUMTEXT, and LONGTEXT, but only the first two correspond to SQLAlchemy's generic String and Text types. Which means I'd have to put MySQLisms in the code to choose LONGTEXT. Also, all these fields could be the target of an advanced search, in which case I'd have to do LIKE on them. That is not a big deal although I think searching on lots of text fields is less than ideal. You can't use indexes with them, although you can't use indexes for LIKE anyway. -- Mike Orr sluggos...@gmail.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: 3rd party client applications accessing pylons model over a local network
Is there some reason you can't connect to the database remotely? That's the most efficient way. Hi Mike, Yes, I've kind of found that trying to do stuff through JSON is not really going to hack it. As it's an Intranet I'm currently installing sqlalchemy and importing a slightly modifed model on each client machine and connecting directly to the DB over the local network (it's an SQlite db) by changing the bind to create_engine. However (and this may be wrong / a stupid question) does doing it this way have issues with concurrent access to the DB? I.e is it pylons / paste server that keeps everything thread safe, or sql alchemy [and therefore ok to do this]? Apologies if I've used the wrong terminology, learning as I go :). Jules --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: 3rd party client applications accessing pylons model over a local network
On Thu, Sep 10, 2009 at 9:19 AM, Jules Stevenson droolz...@googlemail.com wrote: Is there some reason you can't connect to the database remotely? That's the most efficient way. Hi Mike, Yes, I've kind of found that trying to do stuff through JSON is not really going to hack it. As it's an Intranet I'm currently installing sqlalchemy and importing a slightly modifed model on each client machine and connecting directly to the DB over the local network (it's an SQlite db) by changing the bind to create_engine. However (and this may be wrong / a stupid question) does doing it this way have issues with concurrent access to the DB? I.e is it pylons / paste server that keeps everything thread safe, or sql alchemy [and therefore ok to do this]? Apologies if I've used the wrong terminology, learning as I go :). MySQL and PostgreSQL will definitely work for remote access. I wouldn't recommend SQLite for it. Accessing it via a network drive is disrecommended ( http://sqlite.org/whentouse.html, section Client/server applications). In the case of a central Pylons website, Pylons is converting remote web requests to local database queries, so it's not remote database access per se. -- Mike Orr sluggos...@gmail.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: 3rd party client applications accessing pylons model over a local network
2009/9/10 Jules Stevenson droolz...@googlemail.com Is there some reason you can't connect to the database remotely? That's the most efficient way. Hi Mike, Yes, I've kind of found that trying to do stuff through JSON is not really going to hack it. As it's an Intranet I'm currently installing sqlalchemy and importing a slightly modifed model on each client machine and connecting directly to the DB over the local network (it's an SQlite db) by changing the bind to create_engine. However (and this may be wrong / a stupid question) does doing it this way have issues with concurrent access to the DB? I.e is it pylons / paste server that keeps everything thread safe, or sql alchemy [and therefore ok to do this]? Apologies if I've used the wrong terminology, learning as I go :). Jules What do you mean when you say importing a slightly modifed model on each client machine? How different is it and why? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: 3rd party client applications accessing pylons model over a local network
On Wed, Sep 9, 2009 at 2:48 AM, Jules Stevensonli...@js3d.co.uk wrote: If the database itself is accessible over the network (e.g., with MySQL or PostgreSQL), you can write a standalone SQLAlchemy application that users can run on their desktops, which connects to the database via a remote engine. To access the model in the Pylons application, install the application on everybody's desktops, then have the standalone application import the model and call init_model(engine). If the database is not accessible over the network or you prefer to go through a central web application, you can make the application's actions accept JSON input/output instead of HTML, and then write a separate standalone application users would run on their desktops, which packages up their data to JSON and sends it to the web application. Thanks Mike, much appreciated. I've got JSON to work and it's looking pretty good, although possibly a bit slow [I guess because of the HTTP connections overhead, I'm using HTTPlib to do this], however its ease of use probably outweighs any speed benefits :). Is there some reason you can't connect to the database remotely? That's the most efficient way. -- Mike Orr sluggos...@gmail.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
