AntiORM is the ORM that goes against all others

While others ORM isolate the database creating internally SQL queries and DB tables from a class specification, AntiORM create for you a Python function parsing the SQL code, allowing to do more optimized or specialized hand-made queries. It's said: it works exactly the other way ORMs do.

Developed originally as part of the https://github.com/piranna/PirannaFS PirannaFS filesystem project and focused in SQLite, it have been modified to be for general purpose and usable with any other DB-API 2.0 database engines (and also with APSW).

• Python >= 2.6 (by namedtuple, if installed 2.5 by sqlparse)
• sqlparse >=

  0.1.4.92757b0ee0c1543c14f28d3b045ff11ddf5f4297

• byteplay > 0.2 (optional, only needed to

  by-pass types)

1. Create a connection to your database as usual
2. Create an instance of an AntiORM driver (generic or a specific one) passing it

  the connection. You can also use the ''driver_factory'' found at the utils
  module that auto-select the correct backend driver for this connection.
  Optionally, you can also give the path of a directory with SQL
  files (a function will be generated for each file) and also if you want to
  enable the by-pass of the type checking calling directly to the specific
  function, or if queries should be lazy loaded (don't parse the files
  inmediatelly, just wait until they are required for the first time).

1. Optionally, add (more) functions to the AntiORM at any time calling to

  ''parse_dir()'', ''parse_file()'' or ''parse_string()'', giving them a path to
  a folder with SQL files, a path to a SQL file or a SQL string respectively.

1. Finally, call the generated methods on the AntiORM instance using the name

  given (generally the SQL file name without the extension) and giving the
  arguments using a named params style or passing a dictionary. You can also
  pass a list of dictionaries if you need to exec the same generated method
  several times sequentially.

One thing that you must to notice, is that AntiORM doesn't make any check about your code nor generate it. AntiORM assume that the SQL code that you give to it is correct and working, and also that the tables that you use on it really exists on the database, so be sure that you have created them by hand or called an AntiORM generated method that created them for you before trying to do any other operation.

Also, being fully compatible with DB-API 2.0, the rows are returned as a tuple by default. You can be able to return instead a custom object putting a function factory that use the actual cursor and row as parameters, being the only restriction that they could be also able to be accessed by index just like tuples do. You can find a example at antiorm/utils.py module.

Finally, the by-pass of types (currently only working if lazy loading is also enabled) is done modifying the byte-code of the caller function so it points to the correct types one, assuming that at this exact point the source code is doing the method call always with the same parameter types. It's said, you must be sure that if you enabled the bypass_types flag when parsing a SQL query, each different invocation can use different parameter types (keyword args, dict or list of dicts), but they must be called with the same parameter types it was called the first time at each different point on the source code.

• Daniel Cabrera for guidance on

  [https://github.com/piranna/PirannaFS PirannaFS], AntiORM parent project, and
  for recomendations about how to focus the development of AntiORM.

• Andrei Antoukh for huge clean-up and improvement

  of style of the code, and also some guidances about how to speed-up it with
  other colleages from [http://www.python-madrid.es Python Madrid] group.