What would everyone think of some sort of "Philosophy" for the project? In particular, I think it's essential to get something out there that describes the scope of the project. I think everyone saw Ben Bangert's blog post about this; my first impression was that he didn't get the point of Elixir - to allow the programmer to write persisted classes naturally using a good low-level library.
Then I realized that I hadn't read that point anywhere; it was simply what I wanted when I found Elixir, and it worked out OK. So getting some sort of statement of philosophy up would, I think it would help clear up a lot of the ambiguity about what Elixir is trying to do. Of course, it could be that I'm wrong, too :) So, here's something I threw together. (I have a thick skin, throw it away if you wish, it's just a thought.) ## SQL Is Hard Next to HTML, SQL is the the language that many programmers spend the most time interacting with, but not actually writing. Relational databases are a massive topic whose full breadth is outside the reach of most programmers. Nevertheless, they provide an essential abstraction of the data store for programmers, and are not "optional" for use in modern systems. ## What SQLAlchemy Provides SQLAlchemy provides a fantastic interface between object-oriented Python and the primarily declarative SQL. Making full use of Python's extensive introspection, SQLAlchemy is able to provide a surprisingly complete model of SQL in Python. This allows Python programmers to write models - in Python - of their database, and to store, retrieve and query objects in their application code with a far more natural interface than was the case with the multitude of DBAPI libraries. However, while SQLAlchemy provides an interface in Python, the interface is not particularly *Pythonic*. When programmers are trying to define a persistent object, they must explicitly define table and column names they typically don't care about, "naked" classes without any mapping to a database, and then assign mappers to those objects in a third location to handle the ORM step. ## What Elixir Does In complex situations, this fine-grained control over what happens where is extremely useful. For many situations, however, this isn't the case. Many times, a programmer merely wants their ORM to take their objects and persist them; how that task gets accomplished is something the programmer should not have to decide at the early stage of writing their object models. This is what Elixir does: using Python's abstractions, Elixir allows programmers to write Python class definitions, which Elixir will then use to create SQLAlchemy objects. It does not attempt to be a database library; it is merely a way of using SQLAlchemy through a Pythonic, class-based interface. When the programmer needs to define more complex relationships, Elixir "gets out of the way" so that she can use SQLAlchemy to it's full power. Because of this, Elixir is extremely well suited to rapid prototyping by programmers who are already familiar with SQLAlchemy. Please note that using Elixir *requires* knowledge of SQLAlchemy; Elixir simply provides a slightly different entry point. However, when going through rapid changes in object and table structure, Elixir can save the programmer time by not requiring her to update code that may be defined in three places in SQLAlchemy: in the table definition, the object mapper, and in any object methods that make use of the column. While raw SQLAlchemy provides facilities for doing clever things in all three locations, Elixir is ideal for the use case of a plain, simple table definition to be used in an application prototype. While the point can certainly be made that the time spent defining and updating the tables, mappers and objects in SQLAlchemy is relatively low compared to the time spent in application logic, it is also true that in the early stages of development, this definition is not a "one-shot deal" - the programmer is constantly revising and refining the architecture. In these situations, turnaround time takes precedence over the low-level power of SQLAlchemy. In other words, in production systems we expect complex relationships, performance-based normalizations, and oftentimes tight integration with legacy systems. However, the programmer should not be burdened with these implementation details when building an application prototype, or when only simple relations are needed. This is the niche that Elixir intends to fill: by providing a thin layer on top of SQLAlchemy, applications in prototype stage or with only simple relationships can be modeled quickly and with a Pythonic syntax. When fine-grained control is needed, the library that Elixir is built on top of will come to the forefront. Adam Gomaa --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "SQLElixir" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlelixir?hl=en -~----------~----~----~----~------~----~------~--~---
