I am new to Pylons. I love Mako, Routes and the View Controller
concepts behind Pylons.
I am a little unsure of the Model concepts though, and how tightly
they are bound to SQLAlchemy.
In general it seems like a lot of configuration to make simple SQL
queries.
Is there a reason I couldn't
> Is there a reason I couldn't just create a simple model that uses a db
> connection string from the developer.ini conf file and then just make
> direct queries?
We have a pretty big application using PostgreSQL + psycopg2 with no
SqlAlchemy whatsoever, so it's
definitely possible :-)
--
Law
orm is abstraction over database query language. you can make queries
in oo-terms. so your business logic stays clear and you dont care
about object persistence.
also with orm you can change backend (from MySQL to Postgre for ex.)
just
by edit config. if you work with native sql its not always po
> 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 probabl
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
>
Sent from my iPhone
Please excuse any typos ;)
On Jan 22, 2008, at 12:08 AM, "Lawrence Oluyede" <[EMAIL PROTECTED]>
wrote:
>
>> Is there a reason I couldn't just create a simple model that uses a
>> db
>> connection string from the developer.ini conf file and then just make
>> direct queri
> So if I didnt need the portable scheme creation, can I just skip the
> table def in the model?
If you only plan to use raw (text) queries, yes. But then you would need
to write your CREATE TABLE statements by hand, so I'm not sure it would
buy you anything unless you have specific needs.
> Al
Sent from my iPhone
Please excuse any typos ;)
On Jan 22, 2008, at 7:38 AM, "Antoine" <[EMAIL PROTECTED]> wrote:
>
>
>> So if I didnt need the portable scheme creation, can I just skip the
>> table def in the model?
>
> If you only plan to use raw (text) queries, yes. But then you would
> ne
Antoine escreveu:
> Some of that configuration (the table declarations) replaces hand-written
> CREATE TABLE queries, though, and in a more portable way.
>
It's one of those "you have to see it before you believe it" situations.
I've smacked my forehead recently, for not having tried out the O
On Jan 22, 2:33 am, Dmitry Lipovoi <[EMAIL PROTECTED]> wrote:
> orm is abstraction over database query language. you can make queries
> in oo-terms. so your business logic stays clear and you dont care
> about object persistence.
>
> also with orm you can change backend (from MySQL to Postgre for
Sent from my iPhone
Please excuse any typos ;)
On Jan 22, 2008, at 9:11 AM, walterbyrd <[EMAIL PROTECTED]> wrote:
>
> On Jan 22, 2:33 am, Dmitry Lipovoi <[EMAIL PROTECTED]> wrote:
>> orm is abstraction over database query language. you can make queries
>> in oo-terms. so your business logic st
On Jan 22, 2008 5:17 AM, Kevin Baker <[EMAIL PROTECTED]> wrote:
> On Jan 22, 2008, at 3:09 AM, "Antoine" <[EMAIL PROTECTED]> wrote:
>
> I would always use a model unless maybe if there was no db.
I would use a model even if there weren't a db. It keeps your
"business objects" from being too clos
On 22 jan, 10:33, Dmitry Lipovoi <[EMAIL PROTECTED]> wrote:
> orm is abstraction over database query language. you can make queries
> in oo-terms. so your business logic stays clear and you dont care
> about object persistence.
Bullshit.
When using a RDBMS, the database schema is actually 90% (
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
On Jan 22, 2008 1:34 PM, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
>
> On 22 jan, 10:33, Dmitry Lipovoi <[EMAIL PROTECTED]> wrote:
> > orm is abstraction over database query language. you can make queries
> > in oo-terms. so your business logic stays clear and you dont care
> > about object per
On Jan 22, 2008, at 12:11 PM, Mike Orr wrote:
>
> On Jan 22, 2008 5:17 AM, Kevin Baker <[EMAIL PROTECTED]> wrote:
>> On Jan 22, 2008, at 3:09 AM, "Antoine" <[EMAIL PROTECTED]> wrote:
>>
>> I would always use a model unless maybe if there was no db.
>
> I would use a model even if there weren't a
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 thoug
On Jan 22, 2008 4:00 PM, Kevin Baker <[EMAIL PROTECTED]> wrote:
> hmmm this sounds interesting "autoload", I'm guessing this uses the
> table metadata to build the definition? would I find a link to that
> in the SQLAlchemy site?
See "reflecting tables" in the first chapter of the SQLAlchemy man
On 23 jan, 01:13, Kevin Baker <[EMAIL PROTECTED]> wrote:
> 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]>
19 matches
Mail list logo
