Changing the database under SQLObject

I am starting a web project that should probably be fine with SQLite. I have a SQLObject on top of it, but here we are thinking long term - if this project is to require more robust (e.g. capable of handling high traffic), I will need to prepare a migration plan. My questions:

  • How easy is it to go from one DB (SQLite) to another (MySQL or Firebird or PostGre) in SQLObject?
  • Does SQLObject provide any tools to facilitate this transition? Is it just take the objects I have defined and call createTable?
  • How to deal with multiple SQLite databases? For example. one per group of visitors? Does SQLObject provide a mechanism to handle this scenario, and if so, what is the mechanism to use?

Thanks, Sean

+1


source to share


3 answers


3) This is a pretty interesting question. All in all, SQLite is pretty useless for web applications. It scales pretty well for size, but scales horribly for concurrency, and so if you plan on hitting it with multiple requests at the same time, you're in trouble.

Now your idea in part 3) is to use multiple SQLite databases (e.g. one per user group or even one user). Unfortunately, SQLite won't give you any help in this department. But it is possible. One project I know that has done this before is Axmom Divmod . So I will of course check it out.

It would of course be much easier to use a good parallel DB like the ones you mentioned (Firebird, PG, etc.).



For completeness:

1 & 2) This should be simple unless you actually write much code . I find SQLObject a bit restrictive in this department and highly recommend SQLAlchemy instead . It's much more flexible, and if I were to start a new project today, I would of course use it over SQLObject. It will not move "Objects" anywhere. There is no magic here, it will pass rows in tables in the database. Which, as mentioned, can be done manually, but it can save you some time.

+3


source


Your success with createTable () will depend on your existing underlying table / datatype schema. In other words, how well does SQLite match up with your database of choice and how SQLObject decides to use your datatypes.

The safest option is to manually create a new database. Then you have to deal with data migration, which can be as simple as creating two SQLObject database connections using the same table definitions.



Why not just start with a more fully featured database?

+2


source


I'm not sure I understand this question.

The SQLObject documentation contains six available connection types. In addition, the database connection (or schema) is specified in the connection string. Changing database connections from SQLite to MySQL is trivial. Just change your connection string.

The documentation lists the different types of schemas supported.

0


source







All Articles