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]> 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?
Yes. > Is the > main advantage of this abstraction from database specific features in > SQL? It's one of the advantages, but not necessarily the main one. As far as I'm concerned, the main advantage is that you can manipulate your queries as real objects, ie easily add/remove parts of the queries, something which is a real pain to do with sql-as-strings. > I guess I see a huge advantage to the syntax if developer doesn't > know SQL I doubt one can use SQLAlchemy without a decent (at least) knowledge of 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. "never say never" But anyway: SQLALchemy also let you use 'raw' queries, so you can have your cake ant eat it too !-) --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
