Using SQLAlchemy-Migrate with Elixir model in Pylons

I’ve recently come across the database schema migration toolkit that builts on top of the awesome SQLAlchemy ORM library named SQLAlchemy-Migrate. Since I’m working mostly on Pylons projects with extensive schema written using SQL Elixir, I was wondering if I could make SQLAlchemy-Migrate to work with my Elixir models. I’ve managed to make it work perfectly. But before I tell you how, some quick review of the tools and libraries for those of you new to the world of SQLAlchemy.

SQLAlchemy is an Object-Relational Mapper, ORM in short, that maps Python object classes to database objects, i.e.: tables, records, foreign-keys and all the other related stuff. Since SQLAlchemy is an ORM, you don’t have to write sometimes complicated SQL code for querying database. Instead you are working with Python objects and methods. SQLAlchemy adds overhead to SQL query execution times performance, but this tradeoff most of the time is worth it. Trust me. And besides, SQLAlchemy makes your project database engine independent, at least in theory.

Elixir is a declarative-style layer on top of SQLAlchemy that utilizes so called ActiveRecord design pattern. It allows you to use some shortcut methods known mostly from Rails ORM. Elixir is a library that fully interfaces SQLAlchemy and wraps some of the methods and declarations into one Entity. SQLAlchemy as of version 0.6 has declarative layer extension, but it doesn’t have those ActiveRecord methods. Using Elixir is easier than bare SQLAlchemy, but I should warn you, that without understanding SQLAlchemy first you’d be really lost. Elixir is much harder to debug when you stumble upon some kind of non-trivial error, since it’s a wrapper on top of SQLAlchemy.

However Elixir, with some caution and understanding on what you’re doing, can be really satisfactory to work with. Currently I’m working on advanced content management system and I can assure you that it’s model is really complicated. Without Elixir I would be lost long time ago, but since it’s very clean and transparent, just a quick glance at a class based on Elixir Entity gives you complete picture of what’s going on. I very much like it and would recommend using it, especially because you can mix Elixir and SQLAlchemy without any problems provided you know what you’re doing. But enough of this.

So. SQLAlchemy-Migrate. What is it? As I’ve said at the beginning it’s a database schema versioning toolkit built on top of SQLAlchemy. It doesn’t support Elixir out of the box, but with a little trickery you can make it work. What is database schema versioning? Well. It’s a record of changes in database structure between some arbitrary “points in time” called versions. Let’s suppose you have a table in Elixir model defined like this:

class Page(Entity):
    id = Field(Integer, primary_key = True)
    title = Field(Unicode(100))
    content = Field(UnicodeText, required = True)


This is fairly basic Elixir entity that really works. That’s all. You just run setup_all() method from Elixir and you can use this entity in your code querying, updating, inserting and making changes in database. Let’s assume that you use this model and it behaves really well, but when you develop your application further, you find it rather limiting.

For example you wish you could add a new field, so the entity would automatically update creation date and time on inserting new Page record to database. You can alter your model’s Entity like this:

class Page(Entity):
    id = Field(Integer, primary_key = True)
    title = Field(Unicode(100))
    content = Field(UnicodeText, required = True)
    ctime = Field(DateTime, required = True, default =


It will work without any problems, but… Not on existing database. You would either have to issue SQL query directly on the database to bring it up to date with your defined model (i.e. add new column ctime) OR in case of Pylons run paster setup-app which will drop your tables and recreate database from scratch. This is acceptable for new project or development databases, but not on testing (to some degree) or especially production ones, since you would loose all your data.

Here comes SQLAlchemy-Migrate. It’s an extension and toolset built on and working with SQLAlchemy models. It’s intended for schema migration, which is exactly resolving our problem changing and keeping up to date our database table’s structure with our application’s model. Migrate would create repository of changes for your application and create additional table in the database called migrate_version. After creating the repository your database would be at version zero. Official documentation states that this version should represent empty database, in our case empty model.

I’ll digress here a little bit. I’m mostly agreeing with this approach, because it ensures that you’ll build your model from the scratch and then use Migrate to upgrade it to current or desired schema version. There are however some cases when I find it unacceptable and not worth the work. One such case is the CMS I’m currently working on. It’s almost three years worth of work, containing nearly hundred tables, numerous Entity mix-ins, very deep relations of ManyToOne, OneToMany, ManyToMany and other, each table and model class has multitude of methods, decorators and much much more. Rewriting this model according to official documentation guidelines would be really hard work giving virtually no benefits.

What I wanted was to have an established baseline database model that could be extended for this CMS and changes could be committed to the baseline version and further. I need such kind of arrangement, because current version of this application with baseline model is deployed in production for few clients, that I have an agreement with for upgrade, when new versions of the software would be available. This way I could write migration scripts and upgrade their system instances to the latest version, without all the tedious work on writing alternation and schema change scripts in pure SQL, dumping current data and readjusting it to new schema.

SQLAlchemy-Migrate allows me to do this, because each change is registered sequentially as new version of the schema. For each change I write a script with two methods: upgrade and downgrade. First one brings changes up to date and the second drops those changes if you would like to return to previous version of the database schema.

Basically setting a baseline model is a good idea. Official Migrate docs state that database should be empty, but they don’t restrict it such as version zero of migration repository must be empty. Probably it’s related to the problems that might occur when working in teams and you would need to quickly bootstrap new application instance, but I won’t digress here. You can find much information on this topic in the Internet.

The only problem might be that with baseline model must be always in current version of migrate repository. Using your application models IS NOT recommended. There are many problems that can arise from such arrangement and that’s why, according to the Zen Of Python: “Explicit is better than implicit” which means that you have to keep two similar models – one in your application and one in the repository.

Yes. That’s somehow doubling the work, but when you setup a baseline just like me, you can simply track only changes in your migration repository model, updating application model accordingly. Shouldn’t be much work and it’s a good tradeoff for a comfort of having tested and verified database structure upgrade path. And most of those problems that can arise for keeping in sync your two models could be mitigated to some degree by using Mercurial or some other version control system.

Phew. Let’s get back to our problem. How to make SQLAlchemy-Migrate work with Elixir? Let’s suppose that you’d be interested in adding migration facilities to your existing project. I’d assume that you installed sqlalchemy-migrate via pip or easy_install. If so, you’re ready to go.

This is how I’ve setup my migrate repository. First step is to create a migration repository. I have assumed that it will reside under my project’s root directory. The project is under VirtualEnv control and it’s main directory is a subdirectory within the VirtualEnv root. So from my main project directory I have issued:

migrate create migration "Project Repo"


What this basically does is to create a migration subdirectory in the main project’s directory that will hold the sqlalchemy-migrate repository named “Project Repo”. After successful repository creation you must put your database under control. If you’re using Pylons, check out development.ini option sqlalchemy.url, which will give you necessary credentials for your database. To put your database under migrate version control you have to issue:

migrate version_control postgres://login:password@host/database


This will initialize your database for the version control with migrate repository version zero. You also can create a support script which will hold the credentials for your database, so you wouldn’t have to pass those to the migrate script. It’s a convenience script which wraps around migrate. We’ll call it and it can be automatically created by typing in this command:

migrate manage --repository=migration --url=postgres://login:password@host/database

This will create script in your project’s root directory, for repository residing under migration subdirectory and with credentials specified by –url option. Note that I’m using PostgreSQL engine, but you can use whatever engine that SQLAlchemy supports. Note however that SQLite doesn’t support full ALTER statements in SQL, so you might not get results that you’ve expected when using sqlalchemy-migrate. Now you can use:



as a shortcut for your migration repository administration. You can issue:

python version


to check at what version your migration repo is at and you can also use:

python db_version


to see what version of the migration model your database is currently at.

Ok. So we’re finally getting to the juicy part. We have our migration repository setup and ready to use. Let’s establish that our baseline model would be the first version of Page Elixir Entity presented in this post (this without ctime field). We want to create a script that will allow us to create a script for updating our baseline model with this option. Let’s say that we would name this change “Add ctime DateTime field to Page”. We can issue:

python script “Add ctime DateTime field to Page”

This will create a script named migration/versions/ in the migration/versions subdirectory. It will look like this:

from sqlalchemy import *
from migrate import *

def upgrade(migrate_engine):
    # Upgrade operations go here. Don't create your own engine; bind migrate_engine
    # to your metadata

def downgrade(migrate_engine):
    # Operations to reverse the above upgrade go here.


There are two functions: upgrade – which brings database up to date to current version of the script (in this case version 1) and downgrade – which will rollback all the changes created by this version’s changeset (given of course you write the method code).

Since we’re using Elixir and not pure SQLAlchemy, it needs additional setup for each change script. Also having baseline model as our version zero for the migration, we must make sure that we won’t introduce conflicts with our model. If you’re probably familiar with SQLAlchemy, you know that Metadata object instance holds database metadata including database engine bindings. As you can see upgrade and downgrade methods take migrate_engine as their parameter. This is the engine specified by –url option on the migrate script, in our case which will feed the engine automagically. You have to import additional modules in our script:

from sqlalchemy import *
from migrate import *
from elixir import *
import elixir


This will import Elixir and it’s namespace, so we can use Entity, Field and it’s definitions directly, but will also allow us to utilize elixir namespace. This would be needed for engine binding to Elixir’s metadata, since we don’t want to use pure SQLAlchemy metadata. We want to update Entity (and database table) Page accordingly. To do this we should declare Page class which inherits from Entity like this:

import datetime

class Page(Entity):
    using_options(tablename = 'page', autoload = True)
    ctime = Field(DateTime, required = True, default =


This sets up Elixir Entity named Page, which will take our baseline model and add additional field named ctime. This however doesn’t do anything, except loading our Page model from database and declaring additional table field. Take a look at using_options. It has two parameters:

  • tablename – which holds a value of page; and
  • autoload – which is set to True.

What those options do? Option tablename is specifying table name in the database this model will resolve to. This is important, because sometimes when using ManyToMany, Elixir creates distinct names. Second autoload set to True, states that Elixir should load table definition from the database in a way our previously defined fields would be available to us, namely: id, content and title. Defining ctime would cause addition, not substitution of the table fields and in our model.

Note: You could also forget about “autoload = True” in the using_options if you had specified at the top of the script, just right after imports a directive:

options_defaults["autosetup"] = True


But since, we want to have control over our model, I didn’t use it. If you think it’s safe (not many relations), go ahead and use it. Just know what you’re doing. This Entity basically creates a model foundation for upgrade and downgrade functions. So let’s get into them. First we’ll take an upgrade:

def upgrade(migrate_engine):
    # Upgrade operations go here. Don't create your own engine; bind migrate_engine
    # to your metadata
    elixir.metadata.bind = migrate_engine



Wait a second, you would say. Everywhere you’ve looked tutorials bound metadata to global metadata variable which was instantiated as metadata = MetaData(), even those describing Elixir usage with migrate. We’ll. Unfortunately they are all wrong.You have to bind your database engine to Elixir metadata and not the pure SQLAlchemy metadata. This way we don’t need any global MetaData instance and we will be sure that there are no problems with engine_dialect not found errors. That’s basically the magic trick. You could also bind metadata directly to the Elixir Entity table, but that’s too much fuss. If you need that kind of granularity, you probably wouldn’t be reading this tutorial after all. 😉

To actually create a new column for the table, we have to actually point to the table’s column definition and call .create() method on it, so that migrate would create this column with SQL’s ALTER statement. Just remember that SQLite has some limitations. PostgreSQL and MySQL should be perfectly fine. Ok. This is pretty straightforward. Without delay, we’ll do something analogous with downgrade function:

def downgrade(migrate_engine):
    # Operations to reverse the above upgrade go here.
    elixir.metadata.bind = migrate_engine



This causes the column definition to be dropped from database. You can now test our repository change script typing at your command prompt:

python test

And you should see:


This will confirm that migration upgrade to version 1 and downgrade to version 0 is working fine. I could end just here, because that’s almost all you need to know, but unfortunately migrate is a little bitchy with Elixir, when using imported model Entities for using in relations. And with Elixir relations also. I have eaten my teeth on it, but I’ve finally managed to get it up and running perfectly.

Let’s suppose that we want to create another Entity named User, which for clarity would be defined as:

class User(Entity):
    id = Field(Integer, primary_key = True)
    login = Field(Unicode(30), required = True, unique = True)


and it would reside somewhere else, like project_directory.model.entities subdirectory. We want to create a ManyToOne Elixir relation in our Page model with the field name of created_by. Migrate needs a little trickery for this to work. So, let’s suppose that instead of ctime field, we want this created_by relation. We must edit our Page entity accordingly:

from project.model.entities import User

class Page(Entity):
    using_options(tablename = 'page', autoload = True)
    created_by = ManyToOne('User')


This will initialize our model instance of Page with relation to User entity. However, migrate does not know anything about ManyToOne relation, so we would have to fallback to our old, good SQLAlchemy within upgrade and downgrade functions. Since Elixir uses Integer fields for ManyToOne relations with the name constructed as: <RELATION_FIELD_NAME>_<PRIMARY_KEY_FIELD>, given RELATION_FIELD_NAME = created_by, and PRIMARY_KEY_FIELD = id, we would end up with created_by_id field of Integer type. We have to create a relation manually within the upgrade function like this:

def upgrade(migrate_engine):
    # Upgrade operations go here. Don't create your own engine; bind migrate_engine
    # to your metadata
    elixir.metadata.bind = migrate_engine

    clmn = Column('created_by_id', Integer)

    cbid_fk = ForeignKeyConstraint([Page.table.c.created_by_id], [])

    Index('ix_page_created_by_id', Page.table.c.created_by_id).create()


This will add created_by_id Integer field that will be used for relation. Note that we have to define this relation manually. cbid_fk variable would create ForeignKey Constraint on this Integer field which relates to field and adds it to database table definition. Index will create index on this field to speed up lookup. This is how a full ManyToOne relation from Elixir looks under SQLAlchemy. Determining names for ForeignKey and Index should be pretty straightforward for you.

By analogy we define downgrade function. This time however we only need to drop this Integer field. Migrate will take care of removing ForeignKey and Index for us. That’s how this function looks like:

def downgrade(migrate_engine):
    # Operations to reverse the above upgrade go here.
    elixir.metadata.bind = migrate_engine



That’s how you can use Elixir with SQLAlchemy-Migrate using also relations. Perhaps this should be designed better on behalf of Migrate, but this package is pretty awesome and I commend it’s developers with a really useful and easy to use package, that’s really well documented.

Feel free to post comments if you have suggestions for improvement or perhaps better way to force Migrate to work in accord with Elixir. That’s all folks for now. Hopefully you found this useful. Cheers.

About Wolverine

If you are looking for IT consultant, let me know! karol at karoltomala dot REMOVE com Just remove the REMOVE word from the e-mail above!
This entry was posted in Elixir, Programming, Pylons, Python, SQLAlchemy. Bookmark the permalink.

40 Responses to Using SQLAlchemy-Migrate with Elixir model in Pylons

  1. NIL says:


    thanks for this tutorial. However I’m having difficulties at writing a migration script for elixir models, in this use case:

    class Actor(Entity):
    some field

    this class has been removed in the code base

    in the migration upgrade part

    Table(‘actor’, elixir.metadata).drop()

    kills it nicely,

    but in the downgrade part, I can’t manage to recreate the table

    I pasted the class definition in the migration code, tried a setup_all, a setup_entities …. still to no success.

    Would you be kind enough to provide some insight ?

  2. Wolverine says:

    Hello NIL.

    I’m not sure if I understood you correctly, but if you are trying to recreate table when downgrading this is actually pretty simple.

    — cut —

    from sqlalchemy import *
    from migrate import *
    from elixir import *
    import elixir
    class Foo(Entity):
        using_table_options(useexisting = True)
        using_options(tablename = 'foo')
        id = Field(Integer, primary_key = True)
        name = Field(Unicode(20), required = True)
    def upgrade(migrate_engine):
        # Upgrade operations go here. Don't create your own engine; bind migrate_engine
        # to your metadata
        elixir.metadata.bind = migrate_engine
    def downgrade(migrate_engine):
        # Operations to reverse the above upgrade go here.
        elixir.metadata.bind = migrate_engine

    Just remember that within your Entity you have to use using_table_options(useexisting = True) and after you define your Entities you have to do setup_all(). That’s all.

    If you have further questions feel free to ask. Hope this helps!

  3. NIL says:

    thank you for your prompt answer.

    My use case is trickier than that, and my new “table” (that is entity) inherits from others who in turns have many relations, plus they have elixir Statements (row based permission and internationalization).
    It seems I have to import all those as well…
    After some time thinking aout this problem, I’m now heading to a rather low-level approach, using table reflection.

  4. Wolverine says:

    Well, you could manually create ForeignKeyConstraint and Index statements for your relations. This should do, despite it’s a little messy approach.

    However if you’re going with table reflection, may I suggest you write a post about it? Should be an interesting read.


  5. Louis Tan says:

    Hey there. Amazing guide and is going to save me a lot of headaches in the future.

    I never learned any sqlalchemy and opted to use Elixir instead, so I have very little experience with alchemy. I want to make a OneToOne relationship using migrate. Could you provide some insight on how to do so?

    Thanks, really appreciate the help

  6. Wolverine says:

    Hello Louis. Well. AFAIR OneToOne relation is just an ORM thing (which means there are two separate tables managed by the sqlalchemy/elixir). Probably creating two tables in migrate and then using in your model OneToOne relation should do. However I would need to check if it’s so simple.

    It would help you if you knew a little about how sqlalchemy works and then read through elixir relations source code. I’ve been successfully using migrate with elixir this way. Certainly will try to write some tutorials about migrate and elixir when I find some time in the future.

  7. Warlock_29A says:

    hi, try execute migration

    — cut —

    from database.model import Users

    class Socials(object):
    using_options(tablename = ‘sg_socials’, autoload = True)
    users = OneToMany(‘Users’)


    $> python db_migrate/ test
    Get an error when execute this migration (


    ImportError: No module named database.model


  8. Wolverine says:

    Hi Warlock_29A.
    First of all you should make sure your paths are proper. You have to make sure that the path for import is in your PYTHONPATH environment variable when executing this script. Try executing “PYTHONPATH=$PYTHONPATH:. python db_migrate/ test”. If it works you’ll know your paths are screwed. The second error I see is that you are inheriting from “object”. You should inherit from elixir.Entity class.

    Hope this helps.

  9. Warlock_29A says:

    Wolverine, Thanks! It’s work! :)

  10. hneto says:

    Hi, thank you for the great tutorial..

    Maybe you can help me about my problem:

    My migration would add a colum ‘kind’ to table ‘orders’, but I have something different because all my models extend from the same BaseModel (like showed here:

    So, here is the migration file:

    When I run migration ‘test’, I get an Exception:
    Exception: ‘Order’ resolves to several entities, you should use the full path (including the full module name) to that entity.

    It seems that “autoload=True” and “extend_existing=True” (or useexisting=True) don’t work.

    I already tried to change BaseModel to simply Entity.

    Do you have any ideas?

  11. Wolverine says:

    @hneto: Perhaps your imports are screwed. I’m not really sure, because I have never used custom Entity class and I don’t really have time to check how this problem could be resolved. The only option I see in your situation is to study the relevant parts of source code for Migrate and Elixir. This should enlighten you. Sorry, I can’t help, but most of my knowledge regarding those things were from studying source codes. So maybe you should start from there.

  12. miltonlab says:

    Good Article, i need it.
    I add this complete entity in a migration and i don’t need create separately the pensum foreign key.

    class MateriaPensum(Entity):
    nombre = Field(Unicode(1024))
    duracion = Field(Numeric, default=0)
    creditos = Field(Numeric, default=0)
    ciclo = Field(Integer)
    tipo = ManyToOne(‘TipoMateriaPensum’)
    pensum = ManyToOne(‘Pensum’)

  13. Hello,
    Thanks for the write up.
    i seem to be missing one key step to make your simple ctime example work…
    when i run the same update script, the .table attribute of my entity is none so my test fails.
    it seems that Entity is not initiated.
    any ideas as t what i might be missing?

    from sqlalchemy import *
    from migrate import *
    from elixir import *
    import elixir,datetime

    class versions(Entity):
    brandNewFieldTime = Field(DateTime,required=True,

    def upgrade(migrate_engine):
    # Upgrade operations go here. Don't create your own engine; bind
    # migrate_engine to your metadata
    elixir.metadata.bind = migrate_engine

    def downgrade(migrate_engine):
    # Operations to reverse the above upgrade go here.
    elixir.metadata.bind = migrate_engine

  14. は偶然、このウェブサイトにつまずいたが、私はそのリンクをクリックしてくださいうれしいです。あなたが積極的に私は今、いくつかの時間のために答えるために死んでされているすべての質問に答えました。間違いなく、これの多くのために戻ってくるだろう。そんなに

  15. そこに様々な細かい点を作りました。私は主題で検索を行なったし、ほとんどの人があなたのブログに一緒に行くだろうが見つかりました。

  16. ワンダフル サイト。 多くのここに| | 情報情報 参考に有用。 私は 友達 ANS さらに美味しいで共有に送信します。と確か | あなたの、感謝ありがとう!

  17. うわー、素晴らしい話、アイブ氏は、私のFacebookの友人としてあなたを追加しました!これを投稿するための

  18. うーん、私は願っていますいない |、この質問ではなく、どのくらいのんイライラ怒らを取得サイトあなたのように稼ぎますか?

  19. 私は心からあなたのWeb​​ページを読んで喜びを取った、あなたはいくつかのファーストクラスのポイントを説明しています。ビルC(nigrasを参照していないために彼に小道具)からがらくたのこのビットをキャッチ

  20. アン興味深い議論は価格コメントです。 I 感触 あなたがこれに余分な書き込みなければならない 件名、それはよくすることができるではありませんタブートピックが、通常 話個人がに十分ではないような話題に。次へ| に向けへ。 1 、あなたの広告は私のインターネットブラウザをトリガーのサイズを変更するには、あなたがかもしれないあなたのブラックリストにそれを置きたい歓声、私は

  21. コメントを投稿されたものは、私が言う必要があります。本当にめったに私は教育的で楽しいの両方のブログに遭遇していない、と私はあなたを教えてみましょうか、あなたは頭の上に釘を打ってしまっています。あなたの思考が優れています。難易度が十分でない人が周りにインテリジェントに話している一つのことです。イム私はこれに関連する何かを求めるには、このつまずいていることを非常に喜んで。

  22. !信じられないほどのポスト男。ありがとうございますにもかかわらず 私はウルRSSで状況を経験。それに加入することがなぜできないのか分かりません。 取得は同一のRSS 難易誰もがありますか?親切に回答を知っている人。 Thnkx

  23. よろしく、私はこれの大ファンウェブサイト更新に沿って行きたいと思います。

  24. あなたは本当にそれがあなたのプレゼンテーションとそう簡単に見えるように私は実際に私は理解しないだろうと思うものにするために、このトピックを見つけます。それはあまりにも複雑で、私にとっては非常に広いと思われます。 Imはあなたの次のポストのために楽しみにして、私はそれのこつを取得しようよ!私は感銘を受けて

  25. はあなたが見つける のカップル ものの優秀バリアリーフは世界を作るために写真正しくロー​​ドされていない| との いくつかの有名なイルカはちょうどあなたに簡単に頭を与え、あなたが知っているように思ったハウディ

  26. 、あなたは極上の書き込みに使用の記事を、最後のいくつかの記事はちょっと退屈されている…私はあなたのスーパー書き込みを欠場します。 若干トラックのうち、過去のいくつかのポストはちょうどです!にサインアップすることができように| 見える見える 特定特定に食べ物を与える今私は、困難トラブル問題私がすることはできません一度

  27. 。そして、あなたからの応答。車のディーラーは、私が正確に必要な必要が

  28. 私はyouveはいくつかの本当に面白いポイントを作成したと思います。ないだけでなく多くの人々が実際にこれについて、あなただけやったように考えるだろう。このトピックのthatsについてはあまりtheresのが発見され、あなたはとてもうまくやったので、かなりのクラスとすることを純粋に感動イム。優れた1あなた、男!右ここで本当に素晴らしいもの。あなたは多くの人々のようにしている場合

  29. ?イムはそれを作業の考慮、ならびにそれらの人々に、このaは水だけの揺れを追加する場合、私は私は思っていますか?私は人々が最も空想取得し、また、それをブレンドすることができる認識するが、私は多くは私が水だけで混和ならびに進むことができ、その何かを行った大学に私のものを使用することによって朝である迅速な正の何かが必要、私は投資と考えていますその上!同様に長いものがあるようbuyersreとして、相続人はどのようにこのこのようなものですか?バイヤーは私の朝食の交換は、朝の時​​間に暖かいまたは高温環境でこれを取って主張することができますか?私はこれが私のために最も重要な情報の一つであると思います

  30. 私は彼が本質的なを特定されるように友人から電話を得ることが光栄です。ポスト|あなたのウェブログをブラウジングは経験本当の見事な例外的に優れた 。専門家| プロであるとして実績の すべてで私のような考慮の読者に取ってくれてありがとう、と私はあなたを望む多くの ドメイン。

  31. We did a 5hr charlottesville wine tours excursion for 8.

    It was completely collaborated with minimal work on ouur end.

  32. こんにちは、ちょうどあなたを意識するようになりました。特定さ | 実際有益。ブリュッセルのために見に行く| 私は私は。将来的にはこれを継続あなたがすべきである場合には、あなたがあれば私は感謝するでしょう。たくさんの人の男性と女性は でしょうあなたの文章の恩恵を受けました。乾杯!私は{べき本当にすべき|する必要があります| |するべきである – 取得取得私たち、この情報

  33. 初めてアイブ氏は、あなたのブログの良い検索を訪れました!ありがとうございます。無償バージニア炎症を起こしsunshot塩化

  34. は私は最終的には、この時点で文書化されている素晴らしい技術に関する再びお礼を言うためにあなたの精査のビットを構成したいと考えました。それは、多くの人々は主にあなたが今まで決めた場合は、それを行っていることができることを見て、自分でいくつかの現金を作る際に電子書籍として販売のために提供したのと同じものを広範囲に与えることにあなたのような人々の非常に素晴らしく寛大です。これらの戦略は、さらに、他の誰かがこの問題に関して、より優れた取引を発掘するだけで、自分のような同一の情熱を持っていることを確認するための素晴らしい方法を務めていました。私はあなたのWeb​​ページを見て人々のために先に多数のより美しいのインスタンスがあることを知っています。これを議論する時間を割いて

  35. に単にたい入力| 数のカップル 項目、ウェブサイト スタイルは トピック材料がすばらしい威嚇されています。私はこの記事が好き

  36. これがチェックアウトした場合、大きな担当者、あなたの方法をやって来る感謝。しかし、地獄のように有望に見えます! sincerly、クリスティン、、145 Bosepukur Purbapara、コルカタ、WB 700078、インド9748001647はあなたのブログは結構です

  37. の使用を作る例えば「チャンキング」などの作家の練習を。 いくつかの創作演習を含むウェブサイトを彼らが使用しています。作家は、運動を読んで、それを行います。 難易

  38. post.mortgage銀行ニューヨークいただきありがとうございます。これは、方法によって美しいブログです。どこでこのウェブサイトのテーマを得るのですか?

  39. はI 最高視聴 役立つヒント で見つかったの ウェブページ ので 突然のすべて ひどい 感じ ブログオーナー感謝ウェブブログのオーナー。 これらの 人 その結果、 励起 学ぶと絶対に今持っている 享受して を利用して。 私はあなたに感謝 実際にある 単に 役立つ と同様のため これらの種類をこの形式の品質 ヒント に必死には本当に望ましいですへの熱望 について理解発見|上に通知されます。 私の非常に自身の 誠実 謝罪 への感謝の気持ちを表現するないためあなた 以前。

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>