On 8/29/07, AdamG <[EMAIL PROTECTED]> wrote:
> I've been watching Elixir from afar for some time while using
> SQLAlchemy. When using SQLAlchemy I've been using the mapping
> functions inside of SQLAlchemy directly, and like many I've found that
> to be somewhat repetitive and less than intuitive. I had Elixir
> recommended to me by a few people, but the syntax has turned me off to
> it. I'm aware that the DSL nature of it will allow you to create your
> own statements, and I do realize this is a powerful feature, but it's
> not what I was looking for in an ORM wrapper.
>
> I was looking for was a syntax that allowed me to write natural Python
> classes - not unlike what Django's syntax is now, or what TurboEntity
> used to have. A rails-style DSL has it's advantages, but I doubt I'm
> alone in feeling that, if nothing else it /looks/ awkward. Simply put,
> when I want to say that a object will have an integer field, I'd
> expect to write:
>
> class MyObj(ParentClass):
> number = Integer
>
> This is close to both the SQLAlchemy
How is this close to SQLAlchemy?
> and Python ways of doing
> things. On the other hand, I just find that:
>
> class MyObj(ParentClass):
> has_field('number', Integer)
>
> doesn't convey what I was trying to code: I wanted an Object with a
> .number attribute that is an Integer. Putting it into a string means
> that the backend code has to do some setattr(obj, 'number',...) magic,
> and advantages of being able to define your own statements
> notwithstanding, being able to write idiomatic Python code was what I
> was looking for in a declarative layer.
The setattr thing will be there whether you notice it or not.
> So, mostly I'm just wondering if the devs would be amenable to a
> "traditional" syntax for Elixir, and if users would be interested in
> seeing it, or if the DSL syntax is OK for most programmers. I know
> that Ben Bangert brought up this issue back in May and the decision
> was to "steer clear of the discussion" for the time being, but now
> seems like as good a time as any to bring it back up :). I'm not
> averse to starting a separate project for an OOP-style declarative
> layer, but I do want to touch base here to make sure that it isn't
> something that's planned as an Elixir feature.
Ok, here is my take on it. For simple fields, I prefer the OO syntax
too. For relationships, I slightly prefer the DSL style.
In an hypothetical world where there wasn't anybody using the DSL
syntax, I'd personally be ok to go back to an OO style syntax. Now, we
are in the real world, so the DSL syntax is going to stay.
Now, do we want to support both syntax? It wouldn't be hard to do I
think. The problem is with the documentation and how we present
things. That might bring some confusion to have yet another syntax.
On the other hand, I'd find it really a shame if somebody (you or
anybody else) started another declarative layer just because of the
syntax, while most (95% at least) of the codebase could be common. So
honestly, I don't know what to do. I'd be okay to (at least try to)
make the code work both ways, and leave the OO way mostly undocumented
(it would only be an alternative to the "official" syntax) but
Jonathan might not agree with me on this since he likes the DSL thing
a lot (it was his idea after all).
--
Gaëtan de Menten
http://openhex.org
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
