This shares all the same downsides as the existing SA branch. Using an ORM provides very little tangible benefit for non-trivial overhead general obfuscation. The idea of using SA was always just to use it as a cross-DB API, not as an ORM as far as I remember. Really the only benefit is some of the common operations in the model classes are autogenerated, but those are a) only written once per model anyway, b) easy to cut-n-paste from another model, and c) don't change often enough to warrant this kind of complication.
--Noah > -----Original Message----- > From: [email protected] [mailto:[EMAIL PROTECTED] On > Behalf Of Jani Tiainen > Sent: Monday, October 27, 2008 2:56 PM > To: [email protected] > Subject: [Trac-dev] Elixir and Trac > > > Just some random midnight thoughts. (I'm still trying to adjust to > daylight savings time change...) > > Few days ago I stumbled over Elixir <http://elixir.ematia.de/trac/wiki> > (note wiki it uses :) > > In short: "Elixir is a declarative layer on top of the SQLAlchemy > library. It is a fairly thin wrapper, which provides the ability to > create simple Python classes that map directly to relational database > tables (this pattern is often referred to as the Active Record design > pattern), providing many of the benefits of traditional databases > without losing the convenience of Python objects." > > There was/is some experiments made with SQLAlchemy for abstracted db > layer, but what if Trac would use Elixir instead? It could provide more > simpler way to declare Trac entities and remove need of hand crafted > SQL > queries. > > I'm not totally sure but for me current object model seems to be very > close to active record pattern. > > And small sample how it could look like with ticket and ticket_change > tables mapped and, if you look closer, there is even relationships > made. > Look ma', no SQL... just run 'easy_install Elixir' before trying > example. change bind path accordingly and you should be able to see > pretty rudimentary output of your tickets. > > trac_elixir_sample.py: > from elixir import * > > metadata.bind = "sqlite:////var/trac/testproject/db/trac.db" > metadata.bind.echo = False > > class Ticket(Entity): > using_options(tablename="ticket") > id = Field(Integer, primary_key=True) > type = Field(Unicode()) > time = Field(Integer) > changetime = Field(Integer) > component = Field(Unicode) > severity = Field(Unicode) > priority = Field(Unicode) > owner = Field(Unicode) > reporter = Field(Unicode) > cc = Field(Unicode) > version = Field(Unicode) > milestone = Field(Unicode) > status = Field(Unicode) > resolution = Field(Unicode) > summary = Field(Unicode) > description = Field(Unicode) > keywords = Field(Unicode) > changes = OneToMany('TicketChange') > > def __repr__(self): > return repr((self.id, self.type, self.time, self.changetime, > self.component, \ > self.severity, self.priority, self.owner, > self.reporter, self.cc, \ > self.version, self. status, self.resolution, > self.summary, \ > self.description, self.keywords)) > > class TicketChange(Entity): > using_options(tablename="ticket_change") > ticket_id = Field(Integer, colname="ticket", primary_key = True) > time = Field(Integer, primary_key = True) > field = Field(Unicode, primary_key = True) > author = Field(Unicode) > oldvalue = Field(Unicode) > newvalue = Field(Unicode) > ticket = ManyToOne('Ticket', field=ticket_id) > > def __repr__(self): > return repr((self.ticket, self.time, self.field, self.author, > self.oldvalue, self.newvalue)) > > # Application code is here... > setup_all() > for t in Ticket.query.all(): > print t > for c in t.changes: > print c > > > -- > > Jani Tiainen > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Development" 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/trac-dev?hl=en -~----------~----~----~----~------~----~------~--~---
