Re: [Sqlalchemy-users] SQLObject and SQLAlchemy

well there are already two projects in this vein: http://cleverdevil.org/computing/35/declarative-mapping-with-sqlalchemy http://trac.pocoo.org/wiki/DatabaseApi On Mar 26, 2006, at 2:57 PM, David Geller wrote: I realize that this is up to Ian, and I know he has some problems with certain as

Re: [Sqlalchemy-users] SQLObject and SQLAlchemy

I realize that this is up to Ian, and I know he has some problems with certain aspects of SA architecture, but doesn't it make sense for there to be a "SO compatibility layer" to SA, rather then continuing a completely separate SO? This, since it seems SO performs a subset of what SA is capabl

Re: [Sqlalchemy-users] SQLObject and SQLAlchemy

Jonathan Ellis wrote: On 3/24/06, *David Geller* <[EMAIL PROTECTED] > wrote: I realize that SQLAlchemy is far more flexible and extensible than SQLObject. But for simpler things, what exactly are the differences between them? For a newbie starting out,

Re: [Sqlalchemy-users] SQLObject and SQLAlchemy

SQLObject uses validators to ensure that the data coming in for each type of column is valid for that column. Generally speaking, I think that SQLObject is safe from injection attacks, but everyone is definitely in agreement that use bind parameters would be better. Kevin On 3/25/06, Michael Baye

Re: [Sqlalchemy-users] SQLObject and SQLAlchemy

Well I wouldnt panic, it quotes literals so a SQL injection attack is pretty unlikely in most if not all cases...I should not have said that this was a major issue with it. im not sure how it handles numeric literals and such but I would imagine its similarly careful about stuff like that

Re: [Sqlalchemy-users] SQLObject and SQLAlchemy

hi David - I know that Jonathan continues to have strong opinions on this matter. Personally, I think SQLObject is a perfectly good ORM that should remain in wide use. There is one very major issue with it, which is that AFAIK it doesnt use bind parameters which leaves it open to SQL injection a

Re: [Sqlalchemy-users] SQLObject and SQLAlchemy

On 3/24/06, David Geller <[EMAIL PROTECTED]> wrote: I realize that SQLAlchemy is far more flexible and extensible thanSQLObject. But for simpler things, what exactly are the differencesbetween them?For a newbie starting out, what would you say are theadvantages/disadvantages to each? Just that SA's

Re: [Sqlalchemy-users] SQLObject and SQLAlchemy

I realize that SQLAlchemy is far more flexible and extensible than SQLObject. But for simpler things, what exactly are the differences between them? For a newbie starting out, what would you say are the advantages/disadvantages to each? And if what you are doing is fairly "simple", is it worth

Re: [SQLObject] Re: [Sqlalchemy-users] SQLObject and SQLAlchemy

Michael Bayer wrote: There are currently two ways to construct SQL expressions with SQLAlchemy without any knowledge of a database connection or implementation. One is to use the ProxyEngine, which receives a connect() call when you are ready to connect it to something, which occurs only w

Re: [SQLObject] Re: [Sqlalchemy-users] SQLObject and SQLAlchemy

There are currently two ways to construct SQL expressions with SQLAlchemy without any knowledge of a database connection or implementation. One is to use the ProxyEngine, which receives a connect() call when you are ready to connect it to something, which occurs only within the scope of t

Re: [SQLObject] Re: [Sqlalchemy-users] SQLObject and SQLAlchemy

Jonathan Ellis wrote: I've been trying to keep these things extracted from SQLObject2 in the form of SQL-API ( http://svn.sqlobject.org/sqlapi/trunk). I would certainly be interested in reuse on that level, and I'm very open to suggestions and changes, or whatever. It's intended

Re: [SQLObject] Re: [Sqlalchemy-users] SQLObject and SQLAlchemy

On 3/21/06, Ian Bicking <[EMAIL PROTECTED]> wrote: I haven't said SQLObject is a dead end.  I think the codebase needsrethinking, as well as thinking about what its scope should really be.I'll just refer you to my clp discussion with Steve vis a vis the semantics of "dead end." :) And "fragmenting

Re: [SQLObject] Re: [Sqlalchemy-users] SQLObject and SQLAlchemy

Justin Johnson wrote: > Lastly, it would be great if there could be some collaboration on a > combined administration/migration tool, similar in scope to > sqlobject-admin. ORM-specific administration isn't really very useful > -- especially when you can't be sure the ORM describes anything

Re: [SQLObject] Re: [Sqlalchemy-users] SQLObject and SQLAlchemy

> Lastly, it would be great if there could be some collaboration on a > combined administration/migration tool, similar in scope to > sqlobject-admin. ORM-specific administration isn't really very useful > -- especially when you can't be sure the ORM describes anything similar > to what some leg

Re: [SQLObject] Re: [Sqlalchemy-users] SQLObject and SQLAlchemy

My 2c worth: I'd like to see SQLObject 2.0 built on top of SQLAlchemy. Then one would have the best of both worlds: SQLAlchemy's cleaner internals and SQLObjects ease of use. Schiavo Simon -- oo [ hodgestar.za.net ] In the end, we all choose our own moralit

Re: [SQLObject] Re: [Sqlalchemy-users] SQLObject and SQLAlchemy

Jonathan Ellis wrote: On 3/18/06, *Alan Franzoni* <[EMAIL PROTECTED] > wrote: Now, my 2c: do we really need *two* ORMs in the Python community? I agree that we do not. But really this sentiment should be directed towards Ian Bicking; he's finally (implicitly) a

Re: [Sqlalchemy-users] SQLObject and SQLAlchemy

HD Mail wrote: Im really not sure. but it seems to happen, why not just let it happen until some winners become apparent ? seems to be happening already (i.e. the consolidation of "winners"). I think that's what's happening here and we're all saying "Hey, you're both winners, now let's m

Re: [Sqlalchemy-users] SQLObject and SQLAlchemy

Im really not sure. but it seems to happen, why not just let it happen until some winners become apparent ? seems to be happening already (i.e. the consolidation of "winners"). I think that's what's happening here and we're all saying "Hey, you're both winners, now let's make it better to

Re: [Sqlalchemy-users] SQLObject and SQLAlchemy

Daniel Miller wrote: [Jonathan Ellis] [Michael Bayer] you know, back when I first got into Python and wrote Myghty, I got exposed to this whole "oh no theres TOO MANY WEB FRAMEWORKS" thing that was going on, which I suppose is still going on, and my casual, largely uninforme

Re: [Sqlalchemy-users] SQLObject and SQLAlchemy

Michael Bayer wrote: I dont want novices to go away, i just dont want to impose upon the whole community that it reorganize and tailor itself completely to suit the immediate needs of novices, and to discard/dumb down all tools that are "too complicated".clearly I get pretty frustrated ov

Re: [Sqlalchemy-users] SQLObject and SQLAlchemy

[Jonathan Ellis] [Michael Bayer] you know, back when I first got into Python and wrote Myghty, I got exposed to this whole "oh no theres TOO MANY WEB FRAMEWORKS" thing that was going on, which I suppose is still going on, and my casual, largely uninformed impression of it was

Re: [Sqlalchemy-users] SQLObject and SQLAlchemy

On Mar 18, 2006, at 9:51 PM, Jonathan Ellis wrote: And experienced developers come from novice developers, so putting up a "novices go away" sign is suicide, from a community POV. I dont want novices to go away, i just dont want to impose upon the whole community that it reorganize and t

Re: [Sqlalchemy-users] SQLObject and SQLAlchemy

On 3/18/06, Michael Bayer <[EMAIL PROTECTED]> wrote: you know, back when I first got into Python and wrote Myghty, I gotexposed to this whole "oh no theres TOO MANY WEB FRAMEWORKS" thingthat was going on, which I suppose is still going on, and my casual, largely uninformed impression of it was that

Re: [Sqlalchemy-users] SQLObject and SQLAlchemy

you know, back when I first got into Python and wrote Myghty, I got exposed to this whole "oh no theres TOO MANY WEB FRAMEWORKS" thing that was going on, which I suppose is still going on, and my casual, largely uninformed impression of it was that it seemed to be a notion spearheaded prima

Re: [Sqlalchemy-users] SQLObject and SQLAlchemy

On 3/18/06, Daniel Miller <[EMAIL PROTECTED]> wrote: Alan Franzoni wrote:> Now, my 2c: do we really need *two* ORMs in the Python community?I agree with this sentiment as well. If voting would change anything, I'd vote to have SQLObject2 built as a layer on top of SQLAlchemy. If this is not possibl

Re: [Sqlalchemy-users] SQLObject and SQLAlchemy

Alan Franzoni wrote: Now, my 2c: do we really need *two* ORMs in the Python community? I agree with this sentiment as well. If voting would change anything, I'd vote to have SQLObject2 built as a layer on top of SQLAlchemy. If this is not possible, let's hear the reasons so we can fix them.

Re: [Sqlalchemy-users] SQLObject and SQLAlchemy

On 3/18/06, Alan Franzoni <[EMAIL PROTECTED]> wrote: Now, my 2c: do we really need *two* ORMs in the Python community?I agree that we do not.But really this sentiment should be directed towards Ian Bicking; he's finally (implicitly) admitted that SqlObject is a dead end, but instead of throwing his

[Sqlalchemy-users] SQLObject and SQLAlchemy

Hello! I hope this message may help. I'm an ex-SQLObject user and now SQLAlchemy user. I just read on the SO group that sqlobject 0.x is being dropped and a probably backwards incompatible SQLObject 2 is being developed. I think SQLAlchemy is more complex but more coherent, and the recent ActiveMa