On Jan 22, 2008, at 1:46 PM, [EMAIL PROTECTED] wrote:
>
> On 22 jan, 14:17, Kevin Baker <[EMAIL PROTECTED]> wrote:
>> Sent from my iPhone
>> Please excuse any typos ;)
>>
>> On Jan 22, 2008, at 3:09 AM, "Antoine" <[EMAIL PROTECTED]> wrote:
>>
>>>> I am a little unsure of the Model concepts though, and how tightly
>>>> they are bound to SQLAlchemy.
>>
>>> They aren't. Actually, it seems you are not even obliged to use a
>>> Model at
>>> all. You can just write controllers and handle all the logic inside
>>> them
>>> if you want (although many people would probably recommend against
>>> this
>>> :-)).
>>
>> I should have mentioned I am not at all new to MVC or ORM, use them
>> both in java apps often.
>>
>> I would always use a model unless maybe if there was no db.
>
> Even then, you probably want to separate the data (the "model" part)
> from the controller - FWIW, this doesn't necessarily require an OO
> domain layer.
Yup
>
>
>>>> In general it seems like a lot of configuration to make simple SQL
>>>> queries.
>>
>>> Some of that configuration (the table declarations) replaces hand-
>>> written
>>> CREATE TABLE queries, though, and in a more portable way.
>>
>> So if I didnt need the portable scheme creation, can I just skip the
>> table def in the model?
>
> SQLAlchemy can buid it's own stuff from the existing schema.
I'm just finding this out.. I'll dig into that...
>
>
>> Also if I don't plan on ORM, I wouldn't need the object map at all
>> correct?
>
> Yeps. You can just use the "lower" level part of SQLAlchemy.
By lower level, are you referring to the query object notation? Is the
main advantage of this abstraction from database specific features in
SQL? I guess I see a huge advantage to the syntax if developer doesn't
know SQL or if the DB could change... in my case I know SQL well and
have an existing Database that will not be changing... not for the
lifetime of this application anyway.
>
>
>>> Also, SQLAlchemy gives you transparent connection pooling, and other
>>> goodies.
>>
>> Can I use direct queries with engine.execute("select * from") and
>> still take advantage of the goodies?
>
> Yeps again, but this is perhaps not the better thing to do. The nice
> point with SQLAlchemy is that it translates SQL queries into full-
> blown Python objects - which is most of the time far superior to plain
> strings.
>
>
>> I am interested in all pylons and sqlalch have to offer, but am
>> exploring all options, as I'll likely want ORM on case by case basis
>> and would want to skip the extra conf stuff if not needed.
>
> The "extra conf stuff" is in my experience really worth the price. I
> strongly advise you to take a day learning the "lower level" part of
> SQLAlchemy (that is, everything before the ORM part).
>
Thanks again for the advice, I will def take another look at the ORM,
it certainly looks great, I guess I was a bit resistant to learning
yet another "programming" syntax... but I'll have to learn it sometime
being that I love the rest of Pylons.
- Kevin
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"pylons-discuss" group.
To post to this group, send email to pylons-discuss@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~----------~----~----~----~------~----~------~--~---
