Re: Object Relational Mappers are evil (a meditation)
J Kenneth King wrote: In many contexts I'm sure there is reason to use Perl instead of Python just as there are situations where C is more appropriate than either. However, the mark of a poor programmer in my line of reasoning is one who cannot recognize such distinctions. One must be aware of the benefits and short-comings of their tools. If your tools influence the way you think then you are being ignorant of this principle. And I would suggest that makes you a poor programmer. Perhaps influence the way you think is not the right way to phrase it... how about be the tool ;) We have all seen the struggles that newcomers to a language go through as they try (or don't try) to adjust their thinking to the tool at hand -- programming Java, BASIC, FORTRAN, or xyz in Python. Even now Phlip is raging against exceptions and the very Zen of Python. Converting FoxPro to Python is an interesting excercise for me -- version 6 at least doesn't have many of the cool things that Python does, and consequently thinking in Python while writing FoxPro (when I have to) is extremely frustrating; going the other way is a bit of a challenge also, although much more rewarding. For a more concrete example, take sail-boats and speed-boats: you get used to the speed boat, it's quick handling and sharp turns... then you take a sail boat out for a cruise -- if you don't adjust your thinking from speed to sail, you could very well end up in the rocks. To sum up: I agree with your poor programmer line of reasoning in the second paragraph above, but not with the tools influencing the way we think line of reasoning -- while I am cognizant of Python's shortcomings, I am very much enjoying the changes in my thinking the more I use it. ~Ethan~ -- http://mail.python.org/mailman/listinfo/python-list
Re: Object Relational Mappers are evil (a meditation)
Steven D'Aprano st...@remove-this-cybersource.com.au writes: On Wed, 23 Dec 2009 10:55:19 -0500, J Kenneth King wrote: Steven D'Aprano st...@remove-this-cybersource.com.au writes: On Mon, 21 Dec 2009 11:44:29 -0500, J Kenneth King wrote: A programmer that lacks critical thinking is a bad programmer. The language they use has no bearing on such human facilities. That's nonsense, and I can demonstrate it by reference to a single programming language, namely Python. For many years, Python had no ternary if operator: [...] But did the lack of ternary encourage Raymond to become a bad programmer? No, but Raymond started off in a position of being an excellent programmer. A single buggy idiom lead him to be slightly-less excellent than he otherwise would have been. How many buggy idioms would it take to lead him to become a mediocre coder, if he was unable to change languages? Because Python is generally an excellent language, the harm done by one or two misfeatures is minor. But less excellent languages encourage coding styles, techniques and idioms that encourage the programmer to write poor code: either complicated, baroque, unreadable code; or slow inefficient code; or buggy code. To avoid starting a flame war, I will avoid mentioning PHP. *cough* Sometimes you know what you need to do to write non-buggy code, but because covering all the corners are just Too Damn Hard in a certain language, you simply lower your expectations. Error checking is tedious and hard to get right in some languages, like C and Pascal, and hence even good programmers can miss some errors. Different languages encourage different mind-sets in the programmer: C encourages the coder to think at the low level of pointers and addresses, and primarily about machine efficiency; Java encourages the use of big object hierarchies and design patterns (it's hard to write lightweight code in Java, so everything turns into heavyweight code); Perl encourages cleverness and code-golf (writing a program in as few lines or characters as possible); Haskell and Lisp encourage a heavily abstract approach that often requires an elite coder to follow; Forth encourages you to think like Yoda. If anyone continues to follow bad idioms without questioning their usefulness from time to time, I'd question their ability as a programmer. Critical thinking is important. Which is why good programs can be written in PHP, Forth, Lisp, Perl, and anything else. However, if a programmer thinks the only language they will ever need to know is BF, they have a serious screw loose. ;) [...] Good tools make all the difference in the world, I'm not arguing that. You appear to be arguing against that. Maybe you need to reconsider my arguments. It takes a good programmer to recognize the values and trade-offs of the tools they work with. Ignorance is not an excuse to blame the language. It's too easy to say, Well Perl sucks because it encourages you to be a bad programmer because it has all these features that let you shoot yourself in the foot. In reality, lots of really great programs are written in Perl all the time and some very smart people write them. It just so happens that in hands of the educated, those very features are useful in certain cases. Python doesn't encourage you to be a better programmer. It just enforces particular idioms and conventions in its design. As long as the ignorant programmer follows them they should be better off. Yet if they are ignorant, no amount of encouragement will get them to think critically about Python and find bugs in it. They will have to rely on the community of developers to do that thinking for them. Just that the tools don't use us; we use them. Nobody said that tools use us. But it is being suggested that they influence our thinking. Pretty smart thing for a language to be able to do. Programming in Python doesn't instantly make me a better programmer. No, not instantly, but I would argue that after many years of coding in Python you will be a better programmer than after the same number of years of coding in PHP or Basic. And my argument is that the human element is what will determine who is better. There are good programmers who can program in PHP. Some of the biggest websites on the Internet are programmed in it. And like any language I'm sure it has a good number of inefficiencies and bad design decisions that the programmers using it had to work around. Yet despite it being a poor language in your opinion, they built successful programs with it. I wouldn't feel right calling them bad programmers. (large portions of Facebook and Flickr, for example, are written in PHP. They used to be written entirely in PHP before migrating the bottlenecks out to lower-level languages as they scaled up... as is common in most high-level languages) It also depends on what you mean by better programmer. Some languages value
Re: Object Relational Mappers are evil (a meditation)
On 12/24/2009 12:11 PM, Terry Reedy wrote: This buggy idiom survived many years of Python development, missed by virtually everyone. The last statement is false. The hazard of using and/or was well-known back in '97 or so when I discovered or learned it and I believe it was mentioned in the FAQ entry on the subject. The new alternative has the hazard that the condition and if-branch must be written and read in a backwards order. I consider that buggy and do not use it for that reason. Oh really? I thought putting the conditional in the middle was ingenious, whoever thought that must have the next Turing award! I always feel there's something wrong with the (condition ? true : false) or (if condition then true else false) expressions found in other languages; and just realized it was because of their unnatural ordering. I have to admit initially the reversed ordering do confound me, but afterward it felt even more natural than the traditional conditional-first expression. -- http://mail.python.org/mailman/listinfo/python-list
Re: Object Relational Mappers are evil (a meditation)
Steven D'Aprano st...@remove-this-cybersource.com.au writes: On Mon, 21 Dec 2009 11:44:29 -0500, J Kenneth King wrote: A programmer that lacks critical thinking is a bad programmer. The language they use has no bearing on such human facilities. That's nonsense, and I can demonstrate it by reference to a single programming language, namely Python. For many years, Python had no ternary if operator: result = x if condition else y Instead the accepted, idiomatic Python way of writing this was to use short-circuit booleans: result = condition and x or y However this idiom is buggy! If x is a false-value (say, 0) then result gets set to y no matter what the value of condition. This buggy idiom survived many years of Python development, missed by virtually everyone. Even coders of the calibre of Raymond Hettinger (who neither lacks critical thinking nor is a bad programmer) have been bitten by this: The construct can be error-prone. When an error occurs it can be invisible to the person who wrote it. I got bitten in published code that had survived testing and code review: ... http://mail.python.org/pipermail/python-dev/2005-September/056510.html This is a clear and obvious case where a language feature (in this case, the lack of a feature) encouraged an otherwise excellent coder to make an error. It was a very subtle error, which was not picked up by the author, the tests, or the coder reviewer(s). Had Python been different (either by including a ternary if statement, or by forcing and/or to return bools only) then this bug never would have occurred. Of course awful programmers will be awful programmers in any language, and excellent programmers will be excellent programmers in many languages. (I say many rather than any deliberately. There's a reason why nobody uses languages like Brainf*ck, Whitespace, Ook or Intercal for real work.) But most coders are neither awful nor excellent. The language DOES make a difference: the quality of a technician depends partly on the quality of his tools, and programmers are no different. If you don't believe me, imagine writing code in a language without functions or loops, so you have to use GOTO for everything. All very true. But did the lack of ternary encourage Raymond to become a bad programmer? That is what I believe the core of the argument is. Sure the misfeature was over-looked by Raymond, but it took him (and perhaps the help of others) to recognize it and fix it. That's because he's human and the language is inert. He is smart and obviously has the cognitive capabilities to recognize that the language has to change in order to be a better tool. It would be a different story if he just assumed that the misfeature was actually a feature and that it was a good thing. In such a case would Python the language be at fault or the people who write programs with it? Good tools make all the difference in the world, I'm not arguing that. Just that the tools don't use us; we use them. Programming in Python doesn't instantly make me a better programmer. It can certainly make me think of myself as a good programmer though... ;) -- http://mail.python.org/mailman/listinfo/python-list
Re: Object Relational Mappers are evil (a meditation)
On Wed, 23 Dec 2009 10:55:19 -0500, J Kenneth King wrote: Steven D'Aprano st...@remove-this-cybersource.com.au writes: On Mon, 21 Dec 2009 11:44:29 -0500, J Kenneth King wrote: A programmer that lacks critical thinking is a bad programmer. The language they use has no bearing on such human facilities. That's nonsense, and I can demonstrate it by reference to a single programming language, namely Python. For many years, Python had no ternary if operator: [...] But did the lack of ternary encourage Raymond to become a bad programmer? No, but Raymond started off in a position of being an excellent programmer. A single buggy idiom lead him to be slightly-less excellent than he otherwise would have been. How many buggy idioms would it take to lead him to become a mediocre coder, if he was unable to change languages? Because Python is generally an excellent language, the harm done by one or two misfeatures is minor. But less excellent languages encourage coding styles, techniques and idioms that encourage the programmer to write poor code: either complicated, baroque, unreadable code; or slow inefficient code; or buggy code. To avoid starting a flame war, I will avoid mentioning PHP. *cough* Sometimes you know what you need to do to write non-buggy code, but because covering all the corners are just Too Damn Hard in a certain language, you simply lower your expectations. Error checking is tedious and hard to get right in some languages, like C and Pascal, and hence even good programmers can miss some errors. Different languages encourage different mind-sets in the programmer: C encourages the coder to think at the low level of pointers and addresses, and primarily about machine efficiency; Java encourages the use of big object hierarchies and design patterns (it's hard to write lightweight code in Java, so everything turns into heavyweight code); Perl encourages cleverness and code-golf (writing a program in as few lines or characters as possible); Haskell and Lisp encourage a heavily abstract approach that often requires an elite coder to follow; Forth encourages you to think like Yoda. [...] Good tools make all the difference in the world, I'm not arguing that. You appear to be arguing against that. Just that the tools don't use us; we use them. Nobody said that tools use us. Programming in Python doesn't instantly make me a better programmer. No, not instantly, but I would argue that after many years of coding in Python you will be a better programmer than after the same number of years of coding in PHP or Basic. It also depends on what you mean by better programmer. Some languages value cleverness above all else. Python is not a language for writing amazing, awe-inspiring hacks that work where nobody but the author can work out why. This is why there is an Obfuscated C contest and an Obfuscated Perl contest but no Obfuscated Python contest -- it wouldn't be anywhere near as awe-inspiring. So one might argue that the best C and Perl coders are better than the best Python coders, but the average Python coder is better than the average C and Perl coder. (I suggest this as a hypothetical, and do not wish to defend it scientifically.) -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Object Relational Mappers are evil (a meditation)
Instead the accepted, idiomatic Python way of writing this was to use short-circuit booleans: result = condition and x or y However this idiom is buggy! If x is a false-value (say, 0) then result gets set to y no matter what the value of condition. This is only a bug if one expects otherwise. This buggy idiom survived many years of Python development, missed by virtually everyone. The last statement is false. The hazard of using and/or was well-known back in '97 or so when I discovered or learned it and I believe it was mentioned in the FAQ entry on the subject. The new alternative has the hazard that the condition and if-branch must be written and read in a backwards order. I consider that buggy and do not use it for that reason. Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: Object Relational Mappers are evil (a meditation)
On Wed, 23 Dec 2009 20:11:25 -0500, Terry Reedy wrote: Instead the accepted, idiomatic Python way of writing this was to use short-circuit booleans: result = condition and x or y However this idiom is buggy! If x is a false-value (say, 0) then result gets set to y no matter what the value of condition. This is only a bug if one expects otherwise. I'm not saying the behaviour of `a and x or y` is buggy, but that it's use as a replacement for a ternary conditional expression is buggy; the *idiom* is buggy, not the behaviour of and/or. If I say you can make perfect hard boiled eggs by putting the egg in a glass of water in the microwave on high for eight minutes, and the egg explodes, that's not a bug in the microwave, that's a bug in the recipe. This buggy idiom survived many years of Python development, missed by virtually everyone. The last statement is false. The hazard of using and/or was well-known back in '97 or so when I discovered or learned it and I believe it was mentioned in the FAQ entry on the subject. We can argue about how well-known it was for somebody like Raymond Hettinger to miss it, and for whoever did a code-review of his application to also miss it. The new alternative has the hazard that the condition and if-branch must be written and read in a backwards order. If you had asked me a couple of years ago, I would have agreed, but I've now come to the conclusion that `x if condition else y` is not only perfectly natural, but at least as natural as the conventional order of `if condition then x else y` (at least for expressions, not for if statements). Steven, what are you doing on Monday night? Going to the movies if I can get away from work on time, otherwise sitting at home answering questions on comp.lang.python. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Object Relational Mappers are evil (a meditation)
Lie Ryan lie.1...@gmail.com writes: On 12/17/2009 3:17 PM, J Kenneth King wrote: A language is a thing. It may have syntax and semantics that bias it towards the conventions and philosophies of its designers. But in the end, a language by itself would have a hard time convincing a human being to adopt bad practises. Perhaps someone should make a research whether if you teach a language to kids, where one group is taught the language filtered from bad words and another group is taught all the languages' bad words on purpose. Will one group have more behavioral problems compared to the other? I would be curious to know, but the test is likely impossible without trespassing on ethical boundaries. ;) I would hypothesize that you would not find an increase in behavioural problems. a) Without cultural context bad words have little meaning b) Behavioural issues can be attributed to several factors such as physiology, health, environment, etc. c) This has nothing to do with programming languages. A programmer that lacks critical thinking is a bad programmer. The language they use has no bearing on such human facilities. -- http://mail.python.org/mailman/listinfo/python-list
Re: Object Relational Mappers are evil (a meditation)
J Kenneth King wrote: snipple c) This has nothing to do with programming languages. A programmer that lacks critical thinking is a bad programmer. The language they use has no bearing on such human facilities. The language may well have a bearing on the quality of the programs generated though, which is what most people care about. A dolt writing in python is far less likely to write a program that bluescreens the users machine than a comparative dolt writing the same program in C or assembler. Of course two gurus writing in different languages would produce equally good results but gurus are considered gurus by virtue of their scarcity. Back in the real world the further into dolthood you venture, the more the more important the design of the language becomes to the quality of outputs you can expect to get from your code monkeys. Take 100 perfectly average programmers and give them the same programs to write in a variety of languages, you will get higher quality results from some languages than others i.e. not all languages are equal. I think it's fair to say the ones that give the best results encourage good coding and the ones that give the worst results encourage bad coding. If you don't believe it's possible to have a language that encourages bad coding practices consider this one I just made up, I call it Diethon.. It's entirely the same as Python 2.6 except that any syntax errors that happen within class definitions cause the interpreter to send offensive emails to everyone in your contacts list and then delete your master boot record. Unsurprisingly users of this language are reluctant to try to create object oriented code and resort to ugly struct and list based paradigms instead. Roger. -- http://mail.python.org/mailman/listinfo/python-list
Re: Object Relational Mappers are evil (a meditation)
On Mon, 21 Dec 2009 11:44:29 -0500, J Kenneth King wrote: A programmer that lacks critical thinking is a bad programmer. The language they use has no bearing on such human facilities. That's nonsense, and I can demonstrate it by reference to a single programming language, namely Python. For many years, Python had no ternary if operator: result = x if condition else y Instead the accepted, idiomatic Python way of writing this was to use short-circuit booleans: result = condition and x or y However this idiom is buggy! If x is a false-value (say, 0) then result gets set to y no matter what the value of condition. This buggy idiom survived many years of Python development, missed by virtually everyone. Even coders of the calibre of Raymond Hettinger (who neither lacks critical thinking nor is a bad programmer) have been bitten by this: The construct can be error-prone. When an error occurs it can be invisible to the person who wrote it. I got bitten in published code that had survived testing and code review: ... http://mail.python.org/pipermail/python-dev/2005-September/056510.html This is a clear and obvious case where a language feature (in this case, the lack of a feature) encouraged an otherwise excellent coder to make an error. It was a very subtle error, which was not picked up by the author, the tests, or the coder reviewer(s). Had Python been different (either by including a ternary if statement, or by forcing and/or to return bools only) then this bug never would have occurred. Of course awful programmers will be awful programmers in any language, and excellent programmers will be excellent programmers in many languages. (I say many rather than any deliberately. There's a reason why nobody uses languages like Brainf*ck, Whitespace, Ook or Intercal for real work.) But most coders are neither awful nor excellent. The language DOES make a difference: the quality of a technician depends partly on the quality of his tools, and programmers are no different. If you don't believe me, imagine writing code in a language without functions or loops, so you have to use GOTO for everything. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Object Relational Mappers are evil (a meditation)
On 12/17/2009 3:17 PM, J Kenneth King wrote: A language is a thing. It may have syntax and semantics that bias it towards the conventions and philosophies of its designers. But in the end, a language by itself would have a hard time convincing a human being to adopt bad practises. Perhaps someone should make a research whether if you teach a language to kids, where one group is taught the language filtered from bad words and another group is taught all the languages' bad words on purpose. Will one group have more behavioral problems compared to the other? -- http://mail.python.org/mailman/listinfo/python-list
Re: Object Relational Mappers are evil (a meditation)
On 2009-12-16, J Kenneth King ja...@agentultra.com wrote: The language doesn't encourage anything. It's just a medium like oil paints and canvas. A painting can be good or bad despite the medium it is constructed on. The skill of the painter is what matters. Technically, oil paints do encourage a certain kind of painting. They can be layered on top of old paint easily, and they dry slowly, allowing you to slowly build up a painting in layers, and create effects with texture. If you try doing thse things with watercolors, and you'll probably be discouraged. I think a programming language does encourage a certain kind of code. Good code in one language can be poor in another. -- Neil Cerutti -- http://mail.python.org/mailman/listinfo/python-list
Re: Object Relational Mappers are evil (a meditation)
Steven D'Aprano st...@remove-this-cybersource.com.au writes: On Fri, 11 Dec 2009 19:20:21 -0500, Steve Holden wrote: Simon Forman wrote: [...] As far as the OP rant goes, my $0.02: bad programmers will write bad code in any language, with any tool or system or environment they're given. If you want to avoid bad code there's (apparently) no substitute for smrt programmers who are familiar with the tools they're using, not just the syntax but the underlying conceptual models as well. Hear, hear! That's all very well, but some languages and techniques encourage the programmer to write bad code. That's just BS. Bad code doesn't just write itself. Programmers write bad code. And ignorance is not an excuse. Just because a language allows a programmer to write sloppy code doesn't put the language at fault for the bad code programmers write with it. Any half-way decent programmer should be cognisant of when they're writing bad code and when they're writing good code. They should be able to admit that they don't know enough about a language to be writing programs for money in it. They should be able to see anti-patterns and areas of their code that should be re-factored or re-written. The real underlying problem is the human characteristic that allows us to let ourselves believe that we're better than everyone else or more simply, better than we really are. -- http://mail.python.org/mailman/listinfo/python-list
Re: Object Relational Mappers are evil (a meditation)
J Kenneth King wrote: Steven D'Aprano st...@remove-this-cybersource.com.au writes: On Fri, 11 Dec 2009 19:20:21 -0500, Steve Holden wrote: snip Hear, hear! That's all very well, but some languages and techniques encourage the programmer to write bad code. That's just BS. Bad code doesn't just write itself. Programmers write bad code. And ignorance is not an excuse. Just because a language allows a programmer to write sloppy code doesn't put the language at fault for the bad code programmers write with it. Okay, as long as you realize the corollary of your argument is: It is impossible for a language to encourage programmers to write good code and promote good programming practices by design. I'm not sure that's entirely true either. I think python's one way to do something design philosophy goes some way toward that, as does Smalltalk's enforced message passing. I think PHP's superglobals and namespacing encourage bad practices (or used to back in the day), as do Basic's GOTO and Ecmascript's prototype overriding. Surely a language CAN be said to encourage kludges and sloppiness if it allows a good way and a bad way and makes the bad way much easier to implement or understand for noobs. Roger. -- http://mail.python.org/mailman/listinfo/python-list
Re: Object Relational Mappers are evil (a meditation)
r0g aioe@technicalbloke.com writes: J Kenneth King wrote: Steven D'Aprano st...@remove-this-cybersource.com.au writes: On Fri, 11 Dec 2009 19:20:21 -0500, Steve Holden wrote: snip Hear, hear! That's all very well, but some languages and techniques encourage the programmer to write bad code. That's just BS. Bad code doesn't just write itself. Programmers write bad code. And ignorance is not an excuse. Just because a language allows a programmer to write sloppy code doesn't put the language at fault for the bad code programmers write with it. Okay, as long as you realize the corollary of your argument is: It is impossible for a language to encourage programmers to write good code and promote good programming practices by design. I'm not sure that's entirely true either. I think python's one way to do something design philosophy goes some way toward that, as does Smalltalk's enforced message passing. I think PHP's superglobals and namespacing encourage bad practices (or used to back in the day), as do Basic's GOTO and Ecmascript's prototype overriding. I think your corollary is slightly misleading. It would be more apt to say, Just because a language allows a programmer to write good code doesn't mean that the language is responsible for the good code programmers write with it. It is the responsibility of the programmer to recognize the advantages and flaws of their tools. PHP doesn't encourage a programmer to be a bad programmer because it lacks name-spaces or because BASIC has GOTO statements. A bad programmer will be a bad programmer because they don't understand what makes these features distinct, useful, or damaging. The language doesn't encourage anything. It's just a medium like oil paints and canvas. A painting can be good or bad despite the medium it is constructed on. The skill of the painter is what matters. Surely a language CAN be said to encourage kludges and sloppiness if it allows a good way and a bad way and makes the bad way much easier to implement or understand for noobs. Roger. The programmer can be encouraged to use kludges and produce sloppy code. Whether by ignorance or inflated ego. Languages with more choice just give them more rope to hang themselves with. -- http://mail.python.org/mailman/listinfo/python-list
Re: Object Relational Mappers are evil (a meditation)
Neil Cerutti ne...@norwich.edu writes: On 2009-12-16, J Kenneth King ja...@agentultra.com wrote: The language doesn't encourage anything. It's just a medium like oil paints and canvas. A painting can be good or bad despite the medium it is constructed on. The skill of the painter is what matters. Technically, oil paints do encourage a certain kind of painting. They can be layered on top of old paint easily, and they dry slowly, allowing you to slowly build up a painting in layers, and create effects with texture. If you try doing thse things with watercolors, and you'll probably be discouraged. I think a programming language does encourage a certain kind of code. Good code in one language can be poor in another. It's a weak analogy on my part, but I think I do understand what you mean here. In regards to my original point, I think I just came up with a clearer way to express it: A language is a thing. It may have syntax and semantics that bias it towards the conventions and philosophies of its designers. But in the end, a language by itself would have a hard time convincing a human being to adopt bad practises. I believe it's the fault of the programmer who adopts those poor practises. Surely their acceptance of GOTO statements and prototype-overloading are signs of their own preferences and ignorance? It suggests to me that they learnt enough of one language to get by and stopped thinking critically as soon as they sat in front of their keyboard. Throw an idiot behind a Python interpreter and it won't teach them a damn thing unless they're capable of learning it on their own. No matter how well you manage to hard code your conventions into the language. Bad code is written by bad programmers, not bad programming languages. -- http://mail.python.org/mailman/listinfo/python-list
Re: Object Relational Mappers are evil (a meditation)
Paul Rubin wrote: Mick Krippendorf mad.m...@gmx.de writes: If I knew what First Anormal Form was I (hope!) I read it somewhere once, I just can't find or even remember the source. I definitely didn't make it up, though I wish I had. I found exactly one google hit for it, which is this clpy thread. It's a pun on First Normal Form. To transform a schema into First Normal Form you remove repeating groups from the entity and place them in a newly-created entity, leaving a copy of the identifier column behind to express a relationship between the two. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ UPCOMING EVENTS:http://holdenweb.eventbrite.com/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Object Relational Mappers are evil (a meditation)
Simon Forman wrote: [...] As far as the OP rant goes, my $0.02: bad programmers will write bad code in any language, with any tool or system or environment they're given. If you want to avoid bad code there's (apparently) no substitute for smrt programmers who are familiar with the tools they're using, not just the syntax but the underlying conceptual models as well. Hear, hear! regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ UPCOMING EVENTS:http://holdenweb.eventbrite.com/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Object Relational Mappers are evil (a meditation)
On Fri, 11 Dec 2009 19:20:21 -0500, Steve Holden wrote: Simon Forman wrote: [...] As far as the OP rant goes, my $0.02: bad programmers will write bad code in any language, with any tool or system or environment they're given. If you want to avoid bad code there's (apparently) no substitute for smrt programmers who are familiar with the tools they're using, not just the syntax but the underlying conceptual models as well. Hear, hear! That's all very well, but some languages and techniques encourage the programmer to write bad code. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Object Relational Mappers are evil (a meditation)
Aaron Watters aaron.watt...@gmail.com writes: On Oct 16, 10:35 am, mario ruggier mario.rugg...@gmail.com wrote: On Oct 5, 4:25 pm, Aaron Watters aaron.watt...@gmail.com wrote: Occasionally I fantasize about making a non-trivial change to one of these programs, but I strongly resist going further than that because the ORM meatgrinder makes it somewhere between extremely unpleasant and impossible to make any non-trivial changes to a non-trivial program, especially after it has been populated with data. Object-relational mappers are like putting lipstick on a pig:http://gizmoweblog.blogspot.com/2006/10/putting-lipstick-on-pig.html m ;-) Cute, but wrong. Using ORMs is better than using Object databases. In my case I use Python to un data created by java/hibernate. If I was using a java based object database I would be simply stuck. At least if you use an ORM you have a way to access the information without writing a program in the programming language that the ORM was defined in. Anyway, thanks for all the great comments on this thread from all you Sarcopterygii and Haplorrhini out there. Data persistence isn't a one-size fits all problem. It really depends on the needs of the system. Object databases solve the problem of storing complex object graphs, deeply nested data structures, and serializing language-specific objects like continuations or what-have-you (but I think that last one is yet unsolved). We all know what RDBMS' are good for. Neither is perfect for solving every data persistence situation. -- http://mail.python.org/mailman/listinfo/python-list
Re: Object Relational Mappers are evil (a meditation)
On Oct 16, 10:35 am, mario ruggier mario.rugg...@gmail.com wrote: On Oct 5, 4:25 pm, Aaron Watters aaron.watt...@gmail.com wrote: Occasionally I fantasize about making a non-trivial change to one of these programs, but I strongly resist going further than that because the ORM meatgrinder makes it somewhere between extremely unpleasant and impossible to make any non-trivial changes to a non-trivial program, especially after it has been populated with data. Object-relational mappers are like putting lipstick on a pig:http://gizmoweblog.blogspot.com/2006/10/putting-lipstick-on-pig.html m ;-) Cute, but wrong. Using ORMs is better than using Object databases. In my case I use Python to un data created by java/hibernate. If I was using a java based object database I would be simply stuck. At least if you use an ORM you have a way to access the information without writing a program in the programming language that the ORM was defined in. Anyway, thanks for all the great comments on this thread from all you Sarcopterygii and Haplorrhini out there. -- Aaron Watters http://aaron.oirt.rutgers.edu/myapp/GenBankTree/index === SQL is the worst possible data interface language except for all the others. -- Churchill (paraphrased) -- http://mail.python.org/mailman/listinfo/python-list
Re: Object Relational Mappers are evil (a meditation)
On Fri, 2009-10-16 at 01:01 +0200, Mick Krippendorf wrote: Maybe my English (and my memory) is just not so good. I'm german, and here abnormal and anormal are both negations of normal, but with a slight difference in meaning. anormal means just not normal, whereas the meaning of abnormal is more like perverted. That's of course the better word for the case at hand. From my understanding, the prefix ab- comes from latin (away /away from) - which can also be shortened to a in some usages. (e.g. abnormal) The prefix an - which is more commonly shortened to a comes from the greek - meaning without (e.g. anaerobic ) I agree that abnormal would be the better term here - as it does /can have normalisation information, just not in a standardised manner. -- http://mail.python.org/mailman/listinfo/python-list
Re: Object Relational Mappers are evil (a meditation)
Steve Holden wrote: Many such designs make mistakes like using multiple columns (or, even worse, comma-separated values) instead of many-to-many relationships. BTW, the comma-separted-values-in-a-field is officially called the First Anormal Form. There *has to be* some value to it since I've seen it used quite a few times... Mick. -- http://mail.python.org/mailman/listinfo/python-list
Re: Object Relational Mappers are evil (a meditation)
Mick Krippendorf wrote: Steve Holden wrote: Many such designs make mistakes like using multiple columns (or, even worse, comma-separated values) instead of many-to-many relationships. BTW, the comma-separted-values-in-a-field is officially called the First Anormal Form. There *has to be* some value to it since I've seen it used quite a few times... Mick. Just because you've seen something, doesn't mean it has value; just because something has value, doesn't mean the value outweighs the associated disadvantages. I'm not saying you're wrong, just that you may not be right. ;-) ~Ethan~ -- http://mail.python.org/mailman/listinfo/python-list
Re: Object Relational Mappers are evil (a meditation)
Ethan Furman schrieb: Mick Krippendorf wrote: BTW, the comma-separted-values-in-a-field is officially called the First Anormal Form. There *has to be* some value to it since I've seen it used quite a few times... Just because you've seen something, doesn't mean it has value; [...] The setting of irony poti must've been to low... What I really meant to say was: First Anormal Form is despicable, and anyone who uses it schould Rot In Hell For All Eternities To Come! really! :-) Mick. -- http://mail.python.org/mailman/listinfo/python-list
Re: Object Relational Mappers are evil (a meditation)
Ethan Furman et...@stoneleaf.us writes: BTW, the comma-separted-values-in-a-field is officially called the First Anormal Form. There *has to be* some value to it since I've seen it used quite a few times... Mick. Just because you've seen something, doesn't mean it has value; just because something has value, doesn't mean the value outweighs the associated disadvantages. The proliferation of tables required for the pure relational approach is problematic enough that postgresql supports array-valued columns. That comes across to me as an acknowledgement that the benefits of CSV in a field are worth supporting in a somewhat less kludgy way. -- http://mail.python.org/mailman/listinfo/python-list
Re: Object Relational Mappers are evil (a meditation)
Mick Krippendorf wrote: Ethan Furman schrieb: Mick Krippendorf wrote: BTW, the comma-separted-values-in-a-field is officially called the First Anormal Form. There *has to be* some value to it since I've seen it used quite a few times... Just because you've seen something, doesn't mean it has value; [...] The setting of irony poti must've been to low... What I really meant to say was: First Anormal Form is despicable, and anyone who uses it schould Rot In Hell For All Eternities To Come! really! :-) Mick. If I knew what First Anormal Form was I (hope!) I would have seen the irony. But it was still fun to wax philosophical for a moment. ;-) ~Ethan~ -- http://mail.python.org/mailman/listinfo/python-list
Re: Object Relational Mappers are evil (a meditation)
Ethan Furman et...@stoneleaf.us writes: If I knew what First Anormal Form was I (hope!) It appears to be a made-up term. -- http://mail.python.org/mailman/listinfo/python-list
Re: Object Relational Mappers are evil (a meditation)
Ethan Furman schrieb: If I knew what First Anormal Form was [...] This refers to the Normal Forms one goes through when normalizing relational databases. (http://en.wikipedia.org/wiki/Database_normalization#Normal_forms) The First Anormal Form (FAN) means just lumpin' data together in a comma separated string that has to be un-lumped in a program. When there is more than one such program operating on the same FAN-field you can bet they interpret comma separated differently, or one wants the comma separated values sorted and gets confused when the other program inserts values in arbitrary order, or, if the one program expects ints, and the other inserts floats, maybe not even using dotted notation, but commas... you get the picture. In summa: FAN is evil. Mick. -- http://mail.python.org/mailman/listinfo/python-list
Re: Object Relational Mappers are evil (a meditation)
Paul Rubin schrieb: Ethan Furman et...@stoneleaf.us writes: If I knew what First Anormal Form was I (hope!) It appears to be a made-up term. I read it somewhere once, I just can't find or even remember the source. I definitely didn't make it up, though I wish I had. Mick. -- http://mail.python.org/mailman/listinfo/python-list
Re: Object Relational Mappers are evil (a meditation)
Mick Krippendorf mad.m...@gmx.de writes: If I knew what First Anormal Form was I (hope!) I read it somewhere once, I just can't find or even remember the source. I definitely didn't make it up, though I wish I had. I found exactly one google hit for it, which is this clpy thread. -- http://mail.python.org/mailman/listinfo/python-list
Re: Object Relational Mappers are evil (a meditation)
On 2009-10-15 16:37 PM, Paul Rubin wrote: Mick Krippendorfmad.m...@gmx.de writes: If I knew what First Anormal Form was I (hope!) I read it somewhere once, I just can't find or even remember the source. I definitely didn't make it up, though I wish I had. I found exactly one google hit for it, which is this clpy thread. I believe he mistyped it. Try First Abnormal Form: http://www.sqlmag.com/Article/ArticleID/21369/sql_server_21369.html -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco -- http://mail.python.org/mailman/listinfo/python-list
Re: Object Relational Mappers are evil (a meditation)
Robert Kern robert.k...@gmail.com writes: I believe he mistyped it. Try First Abnormal Form: http://www.sqlmag.com/Article/ArticleID/21369/sql_server_21369.html Ah, that makes sense. Article is subscriber-only but would seem to explain the situation. -- http://mail.python.org/mailman/listinfo/python-list
Re: Object Relational Mappers are evil (a meditation)
Mick Krippendorf mad.m...@gmx.de writes: Paul Rubin schrieb: Ethan Furman et...@stoneleaf.us writes: If I knew what First Anormal Form was I (hope!) It appears to be a made-up term. I read it somewhere once, I just can't find or even remember the source. I definitely didn't make it up, though I wish I had. The word “anormal” appears to have been made up by you. The negation of the word “normal” is “abnormal”, perhaps you meant “First Abnormal Form”? That term was in use when E. F. Codd was originally describing the normal forms, and seemed to imply a database that was in even worse shape than 0NF. More recently, this witty commenter at Daily WTF has defined a plausible (though certainly not universally-agreed) set of abnormal forms URL:http://thedailywtf.com/Comments/Roll_Your_Own_Clustered_Index.aspx#121564. -- \“Nothing so needs reforming as other people's habits.” —Mark | `\ Twain, _Pudd'n'head Wilson_ | _o__) | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: Object Relational Mappers are evil (a meditation)
Ben Finney schrieb: Mick Krippendorf mad.m...@gmx.de writes: The word “anormal” appears to have been made up by you. The negation of the word “normal” is “abnormal”, perhaps you meant “First Abnormal Form”? Maybe my English (and my memory) is just not so good. I'm german, and here abnormal and anormal are both negations of normal, but with a slight difference in meaning. anormal means just not normal, whereas the meaning of abnormal is more like perverted. That's of course the better word for the case at hand. That term was in use when E. F. Codd was originally describing the normal forms, and seemed to imply a database that was in even worse shape than 0NF. More recently, this witty commenter at Daily WTF has defined a plausible (though certainly not universally-agreed) set of abnormal forms URL:http://thedailywtf.com/Comments/Roll_Your_Own_Clustered_Index.aspx#121564. That's better. I'll keep googling though, because I distinctly remember, if nothing else, that I have read First Abnormal Form being used for the comma separation stuff. Mick. -- http://mail.python.org/mailman/listinfo/python-list
Re: Object Relational Mappers are evil (a meditation)
On Oct 5, 7:25 am, Aaron Watters aaron.watt...@gmail.com wrote: This is a bit off topic except that many Python programmers seem to be allergic to typing SQL. RESOLVED: Using ORMs leads lazy programmers to make bad database designs. It's better to carefully design your database with no invisible means of support and there is no reason to not use SQL directly for this purpose. Yeah sure, whatever. I'm sure a good programmer could use sql directly and produce a tighter, faster, better-performing application than an ORM-solution, same as you could use C to produce a tighter, faster, better-performing application than a pure Python one. No thanks, you can write your databases in database assembly language if you want, I'll stick to my ORM, tyvm. Isn't WordPress written in PHP? Are ORMs even possible in PHP? I can almost rationalize use of direct sql if the alternative is some hellspawn PHP ORM. Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
Re: Object Relational Mappers are evil (a meditation)
Carl Banks a écrit : On Oct 5, 7:25 am, Aaron Watters aaron.watt...@gmail.com wrote: This is a bit off topic except that many Python programmers seem to be allergic to typing SQL. RESOLVED: Using ORMs leads lazy programmers to make bad database designs. It's better to carefully design your database with no invisible means of support and there is no reason to not use SQL directly for this purpose. Yeah sure, whatever. I'm sure a good programmer could use sql directly and produce a tighter, faster, better-performing application than an ORM-solution, same as you could use C to produce a tighter, faster, better-performing application than a pure Python one. It's certainly way easier to write good SQL than to write a good C program, and even when using an ORM, it's sometimes worth going down to hand-written SQL queries for some more or less complex cases. But I guess this falls in the same category as recoding a couple core functions in C for improved performances. Isn't WordPress written in PHP? Are ORMs even possible in PHP? There are (alas) some attempts. Nothing close to SQLAlchemy nor even Django's - PHP is just not hi-level enough. I can almost rationalize use of direct sql if the alternative is some hellspawn PHP ORM. What _could_ possibly be done in PHP would at least be a higher-level representation of sql expressions, that would make it easier to dynamically build / modifie / combine queries. Working with SQL as raw strings is both tiresome and error-prone when it comes to dynamically generate complex queries. That part is IMHO *much* more important than mapping tuples to objects. -- http://mail.python.org/mailman/listinfo/python-list
Re: Object Relational Mappers are evil (a meditation)
Diez B. Roggisch a écrit : Aaron Watters schrieb: (snip) FOR EXAMPLE: Consider blogging. The most successful blog software is WORDPRESS. Here is the WordPress data model: http://blog.kapish.co.in/wp-content/uploads/2009/03/wp_2.7.png (snip) Now let's look at the Sakai Blogger tool data model (snip) confluence.sakaiproject.org/download/attachments/17072138/ entitymodel.pdf I think your example is nonsense. Just comparing the two models based on they both are for blogging FWIW, sakai seems to be a wiki, not a blog. And I would add that not having a nice graphical *representation* of a schema doesn't imply the schema is wrong from a relational design POV. -- http://mail.python.org/mailman/listinfo/python-list
Re: Object Relational Mappers are evil (a meditation)
On Tue, Oct 6, 2009 at 2:00 AM, Carl Banks pavlovevide...@gmail.com wrote: On Oct 5, 7:25 am, Aaron Watters aaron.watt...@gmail.com wrote: This is a bit off topic except that many Python programmers seem to be allergic to typing SQL. RESOLVED: Using ORMs leads lazy programmers to make bad database designs. It's better to carefully design your database with no invisible means of support and there is no reason to not use SQL directly for this purpose. Yeah sure, whatever. I'm sure a good programmer could use sql directly and produce a tighter, faster, better-performing application than an ORM-solution, same as you could use C to produce a tighter, faster, better-performing application than a pure Python one. No thanks, you can write your databases in database assembly language if you want, I'll stick to my ORM, tyvm. Isn't WordPress written in PHP? Are ORMs even possible in PHP? I can almost rationalize use of direct sql if the alternative is some hellspawn PHP ORM. I recently had the uncomfortable task of picking an ORM to use in a php project for a start up. There's something called RedBean http://www.redbeanphp.com/ that's actually pretty effin sweet (IMHO). Sweet enough that I'm considering porting it to python. It's more of a RAD tool than something you'd want to use in production. As far as the OP rant goes, my $0.02: bad programmers will write bad code in any language, with any tool or system or environment they're given. If you want to avoid bad code there's (apparently) no substitute for smrt programmers who are familiar with the tools they're using, not just the syntax but the underlying conceptual models as well. That said, I feel ya bro' -- http://mail.python.org/mailman/listinfo/python-list
Re: Object Relational Mappers are evil (a meditation)
Aaron Watters a écrit : This is a bit off topic except that many Python programmers seem to be allergic to typing SQL. What I am mostly allergic to is manipulating sql queries as strings and resultsets as lists of tuples. I strongly prefer a higher level representation of both the queries and the resultsets. From this POV, SQLAlchemy or Django's ORM are better than the primitive scheme above - and don't have that much impact on db design. RESOLVED: Using ORMs leads lazy programmers to make bad database designs. to me, a lazy programmer is someone that is mostly concerned with not repeating itself. As such, lazy usually ends up with better designs (db or whatever) !-) It's better to carefully design your database with no invisible means of support and there is no reason to not use SQL directly for this purpose. I don't use SQL to *design* my databases, I use SQL (directly or indirectly) to create and mananage my schemas and datas. For the design part, I usually start with a pencil and some paper. (snip remaining rant). -- http://mail.python.org/mailman/listinfo/python-list
Re: Object Relational Mappers are evil (a meditation)
Aaron Watters schrieb: This is a bit off topic except that many Python programmers seem to be allergic to typing SQL. RESOLVED: Using ORMs leads lazy programmers to make bad database designs. It's better to carefully design your database with no invisible means of support and there is no reason to not use SQL directly for this purpose. FOR EXAMPLE: Consider blogging. The most successful blog software is WORDPRESS. Here is the WordPress data model: http://blog.kapish.co.in/wp-content/uploads/2009/03/wp_2.7.png Beautiful, isn't it? It was designed by people who thought about what they were doing and did it carefully. Now let's look at the Sakai Blogger tool data model (as reverse engineered by someone who had to fix a bug -- there actually was no data design created by the implementers): confluence.sakaiproject.org/download/attachments/17072138/ entitymodel.pdf How did the above happen? I suspect someone opened up Eclipse and started typing, relying on the Hibernate ORM to handle all the database stuff automagically. The result is a massive headache for people like me. Another one. I routinely open up the mysql prompt and start typing show tables, describe table blah, select * from blah limit 10... trying to figure out WTF Hibernate did with my data. I think your example is nonsense. Just comparing the two models based on they both are for blogging is like comparing a cessna to a 747 - yes, both are flying, but that's pretty much what they have in common. It is pretty clear that sakai's data-model caters to a very sophisticated *user*-model, with roles and permissions, and whatnot. Plus other features. So it appears to be more in the CMS-league. Now it's obviously easy to argue that this isn't needed for a simple blog. Nonetheless, it doesn't make a point about ORM. With any ORM I know (both in Java and Python) you could design the simple and straight model WP uses. And I've seen my fair share of convoluted, trashy pure-SQL-based DBs as well. So I think to make your point you need some more convincing arguments. Diez -- http://mail.python.org/mailman/listinfo/python-list
Re: Object Relational Mappers are evil (a meditation)
Diez B. Roggisch wrote: Aaron Watters schrieb: This is a bit off topic except that many Python programmers seem to be allergic to typing SQL. RESOLVED: Using ORMs leads lazy programmers to make bad database designs. It's better to carefully design your database with no invisible means of support and there is no reason to not use SQL directly for this purpose. FOR EXAMPLE: Consider blogging. The most successful blog software is WORDPRESS. Here is the WordPress data model: http://blog.kapish.co.in/wp-content/uploads/2009/03/wp_2.7.png Beautiful, isn't it? It was designed by people who thought about what they were doing and did it carefully. Now let's look at the Sakai Blogger tool data model (as reverse engineered by someone who had to fix a bug -- there actually was no data design created by the implementers): confluence.sakaiproject.org/download/attachments/17072138/ entitymodel.pdf How did the above happen? I suspect someone opened up Eclipse and started typing, relying on the Hibernate ORM to handle all the database stuff automagically. The result is a massive headache for people like me. Another one. I routinely open up the mysql prompt and start typing show tables, describe table blah, select * from blah limit 10... trying to figure out WTF Hibernate did with my data. I think your example is nonsense. Just comparing the two models based on they both are for blogging is like comparing a cessna to a 747 - yes, both are flying, but that's pretty much what they have in common. It is pretty clear that sakai's data-model caters to a very sophisticated *user*-model, with roles and permissions, and whatnot. Plus other features. So it appears to be more in the CMS-league. It's also pretty clear that the person who developed the sakai map had nothing to guide them, making it difficult to divine any structural regularity that may be present in the design. The entity-relationship diagram doesn't even show the cardinality of the relationships, making it much less useful than it otherwise might be. As a result the whole thing looks like a dog's breakfast. Now it's obviously easy to argue that this isn't needed for a simple blog. Nonetheless, it doesn't make a point about ORM. With any ORM I know (both in Java and Python) you could design the simple and straight model WP uses. And I've seen my fair share of convoluted, trashy pure-SQL-based DBs as well. Yup, me too. Many such designs make mistakes like using multiple columns (or, even worse, comma-separated values) instead of many-to-many relationships. Sad how such elegant tools are so badly abused so often, isn't it? So I think to make your point you need some more convincing arguments. It seems to me that the biggest sin in databases is a failure to use rigorous design techniques. If somebody doesn't understand relational theory then they will probably not design database representations that are easy to work with. If they do understand then the designs they produce will operate just as easily with object relational mappers as they do with direct SQL. I suspect Aaron was really complaining about ignorance rather than laziness (though the two do sometimes go together, and the former is often but by no means invariably caused by the latter). But he'd have to confirm or deny that. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ Watch PyCon on video now! http://pycon.blip.tv/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Object Relational Mappers are evil (a meditation)
Steve Holden st...@holdenweb.com writes: It seems to me that the biggest sin in databases is a failure to use rigorous design techniques. If somebody doesn't understand relational theory Where does one find out about this? I've somehow managed to avoid it for an awfully long time, but it begins to look useful. Thanks. -- http://mail.python.org/mailman/listinfo/python-list
Re: Object Relational Mappers are evil (a meditation)
Paul Rubin http://phr...@nospam.invalid writes: Steve Holden st...@holdenweb.com writes: It seems to me that the biggest sin in databases is a failure to use rigorous design techniques. If somebody doesn't understand relational theory Where does one find out about this? I've somehow managed to avoid it for an awfully long time, but it begins to look useful. Thanks. Wikipedia's article URL:http://en.wikipedia.org/wiki/Relational_model and at the original Wiki URL:http://c2.com/cgi/wiki?RelationalModel are good introductions to the concepts of the topic. The works of C. J. Date, especially (in my view) “Database In Depth” URL:http://en.wikipedia.org/wiki/Special:BookSources/0596100124 and the further reading recommended at the Wikipedia article URL:http://en.wikipedia.org/wiki/Relational_model#Further_reading URL:http://en.wikipedia.org/wiki/Special:BookSources/0321197844 URL:http://en.wikipedia.org/wiki/Special:BookSources/0201709287, are solid groundings in the topic for programming practitioners. In learning about the relational model, you'll inevitably learn that SQL is rather flawed in its implementation of that model. Nevertheless, it turns out to be the best (largely because most widespread) language for describing a relational database, *if* used with knowledge of the relational model to avoid those implementation flaws. -- \ “As scarce as truth is, the supply has always been in excess of | `\ the demand.” —Josh Billings | _o__) | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: Object Relational Mappers are evil (a meditation)
On Mon, Oct 5, 2009 at 11:14 PM, Paul Rubin http://phr...@nospam.invalid wrote: Steve Holden st...@holdenweb.com writes: It seems to me that the biggest sin in databases is a failure to use rigorous design techniques. If somebody doesn't understand relational theory Where does one find out about this? I've somehow managed to avoid it for an awfully long time, but it begins to look useful. Thanks. Go to the source: The relational model for database management by E. F. Codd http://portal.acm.org/citation.cfm?id=77708 -- http://mail.python.org/mailman/listinfo/python-list
Re: object-relational mappers
M.-A. Lemburg wrote: On 2008-04-01 22:40, Aaron Watters wrote: I've been poking around the world of object-relational mappers and it inspired me to coin a corellary to the the famous quote on regular expressions: You have objects and a database: that's 2 problems. So: get an object-relational mapper: now you have 2**3 problems. That is to say I feel that they all make me learn so much about the internals and features of the O-R mapper itself that I would be better off rolling my own queries on an as-needed basis without wasting so many brain cells. comments? I fully agree :-) BTW: Some people implemented O/R mappers above python-ldap. All implementations I saw up to now are falling short regarding the complexity of the LDAP attribute sub-types, the syntactical rules for attribute type descriptive names and attribute name aliasing. So first a developer has also to evaluate whether a O/R mapper is really complete before using it. Ciao, Michael. -- http://mail.python.org/mailman/listinfo/python-list
Re: object-relational mappers
On 2 Apr, 15:50, Aaron Watters [EMAIL PROTECTED] wrote: [Quoting hdante] Seriously, you'll forget there's a relational database below. (there are even intefaces for relational lists, trees, etc.) My experience with this sort of thing is that it is a bit like morphine. It can feel really good, and in emergencies it can save you a lot of pain. But if you use it too often and too seriously you end up with really big problems. That's two candidates for quote of the week in the same thread! I agree with those who question why you'd want to treat a relational database like a big dictionary, and although the interface between queries, results and program data structures can often seem quite awkward, I've come to realise that most object-relational mappers are solving the wrong problems: they pretend that the database is somehow the wrong representation whilst being a fast enough black box for holding persistent data (although I doubt that many people push the boundaries enough to see that it's not possible to ignore all details of such a database whilst preserving performance), or they pretend that languages like SQL (which can be cumbersome, admittedly) are inconvenient for querying whilst replicating a less concise mechanism for querying using client language mechanisms. I'm more encouraged by the idea of query templating, which might sound like a recipe for all sorts of problems, but if done right could provide more effective ways of working with relational databases than pretending that different things in the database are somehow objects in the client language sense. Paul -- http://mail.python.org/mailman/listinfo/python-list
Re: object-relational mappers
Paul Boddie wrote: ... I've come to realise that most object-relational mappers are solving the wrong problems: they pretend that the database is somehow the wrong representation whilst being a fast enough black box for holding persistent data (although I doubt that many people push the boundaries enough to see that it's not possible to ignore all details of such a database whilst preserving performance), or they pretend that languages like SQL (which can be cumbersome, admittedly) are inconvenient for querying whilst replicating a less concise mechanism for querying using client language mechanisms. bit-of-a-rant Well at the risk of oversimplifying (!) I find there are two kinds of programmers using databases: those, like me, for whom the database is the application and who can happily envisage any number of interfaces, human and otherwise, to the data; and those, like 70% of the people I've ever interviewed for a job as a SQL developer, for whom the interface is the application and who simply throw things at whatever database they're presented with. The former will more likely tend to reach first for SQL to retrieve their data efficiently before passing it on to the front end for presentation or manipulation. The latter (and I've seen this far too often in interviews) will basically do SELECT * FROM x WHERE y to pull everything back into their VB.Net app where they feel more at home. Or, in the case of Python, reach for an ORM. I've recently used Elixir and found it very useful for a small-scale database with no more than a dozen tables, well-structured and easily understood. I'd certainly use it again for anything like that to save me writing what would amount to boilerplate SQL. But I'd hate to imagine it in the context of my day job: a messy, organic and sprawling SQL Server database with over 1,000 tables, let alone views, procedures and so on. /bit-of-a-rant TJG -- http://mail.python.org/mailman/listinfo/python-list
Re: object-relational mappers
Tim Golden wrote: I've recently used Elixir and found it very useful for a small-scale database with no more than a dozen tables, well-structured and easily understood. I'd certainly use it again for anything like that to save me writing what would amount to boilerplate SQL. But I'd hate to imagine it in the context of my day job: a messy, organic and sprawling SQL Server database with over 1,000 tables, let alone views, procedures and so on. That's the scenario where the rest of SQLAlchemy (beyond Elixir, that is, and with reflection turned to 11) can do mucho bueno. -- http://mail.python.org/mailman/listinfo/python-list
Re: object-relational mappers
Marco Mariani wrote: Tim Golden wrote: I've recently used Elixir and found it very useful for a small-scale database with no more than a dozen tables, well-structured and easily understood. I'd certainly use it again for anything like that to save me writing what would amount to boilerplate SQL. But I'd hate to imagine it in the context of my day job: a messy, organic and sprawling SQL Server database with over 1,000 tables, let alone views, procedures and so on. That's the scenario where the rest of SQLAlchemy (beyond Elixir, that is, and with reflection turned to 11) can do mucho bueno. Well, true (and I've done good things with it) but, ultimately if I need to write SQL I'll write SQL: that's what I'm paid for. And no matter how good sa's generative queries are -- and they are good -- I've been writing complex SQL queries for 15 years and learning a more Pythonesque equivalent doesn't really seem to offer me anything. Not to take away from the achievements of SqlAlchemy: I'm just not really the target market, I think. TJG -- http://mail.python.org/mailman/listinfo/python-list
Re: object-relational mappers
I have come to the same conclusion.
ORMs make easy things easier, but difficult things impossible...
The best approach I've seen so far is webpy's (if we are talking of
web apps).
It isn't an ORM, it is just a way to make the database api easier to
use.
Queries don't return objects, they return something similar to
dictionaries, which can be used with dot notation ( for example,
result.name is equal to result['name'] ).
A simple select query would be db.select('customers') or
db.select('customers', name='John').
But you can also resort to plain sql as follows: db.query('select *
from customers where name = John').
Simple, effective and doesn't get in your way.
Luis
--
http://mail.python.org/mailman/listinfo/python-list
Re: object-relational mappers
Bruno Desthuilliers napisał(a): Now my own experience is that whenever I tried this approach for anything non-trivial, I ended up building an ad-hoc, informally-specified bug-ridden slow implementation of half of SQLAlchemy. Which BTW is not strictly an ORM, but primarily an attempt at a better integration of SQL into Python. So while it may feel like learning the inner complexities of SQLALchemy (or Django's ORM which is not that bad either) is wasting brain cells, MVHO is that it's worth the time spent. But YMMV of course - IOW, do what works best for you. I like OR mappers, they save me lot of work. The problem is, all of them are very resource hungry, processing resultset of 300k objects one by one can effectively kill most of commodity systems. This is where raw SQL comes in handy. -- Jarek Zgoda Skype: jzgoda | GTalk: [EMAIL PROTECTED] | voice: +48228430101 We read Knuth so you don't have to. (Tim Peters) -- http://mail.python.org/mailman/listinfo/python-list
Re: object-relational mappers
Luis M. González a écrit :
I have come to the same conclusion.
ORMs make easy things easier, but difficult things impossible...
Not my experience with SQLAlchemy. Ok, I still not had an occasion to
test it against stored procedures, but when it comes to complex queries,
it did the trick so far - and (warning: front-end developper
considerations ahead) happened to be much more usable than raw strings
to dynamically *build* the queries.
The best approach I've seen so far is webpy's (if we are talking of
web apps).
It isn't an ORM, it is just a way to make the database api easier to
use.
Queries don't return objects, they return something similar to
dictionaries, which can be used with dot notation ( for example,
result.name is equal to result['name'] ).
A simple select query would be db.select('customers') or
db.select('customers', name='John').
But you can also resort to plain sql as follows: db.query('select *
from customers where name = John').
Simple, effective and doesn't get in your way.
Seems nice too in another way. Is that part independant of the rest of
the framework ? If so, I'll have to give it a try at least for admin
scripts.
--
http://mail.python.org/mailman/listinfo/python-list
Re: object-relational mappers
Bruno Desthuilliers wrote:
A simple select query would be db.select('customers') or
db.select('customers', name='John').
But you can also resort to plain sql as follows: db.query('select *
from customers where name = John').
Simple, effective and doesn't get in your way.
Seems nice too in another way.
And no different than using SQLAlchemy's sa.select() or
engine.execute(), after all.
Is that part independant of the rest of the framework ? If so, I'll
have to give it a try at least for admin
scripts.
My admin scripts go through SQLAlchemy as well, I just have some issues
with postgres' COPY statement -- but I don't know if the DBAPI is
supposed to handle that.
--
http://mail.python.org/mailman/listinfo/python-list
Re: object-relational mappers
Jarek Zgoda a écrit : Bruno Desthuilliers napisał(a): Now my own experience is that whenever I tried this approach for anything non-trivial, I ended up building an ad-hoc, informally-specified bug-ridden slow implementation of half of SQLAlchemy. Which BTW is not strictly an ORM, but primarily an attempt at a better integration of SQL into Python. So while it may feel like learning the inner complexities of SQLALchemy (or Django's ORM which is not that bad either) is wasting brain cells, MVHO is that it's worth the time spent. But YMMV of course - IOW, do what works best for you. I like OR mappers, they save me lot of work. The problem is, all of them are very resource hungry, processing resultset of 300k objects one by one can effectively kill most of commodity systems. This is where raw SQL comes in handy. The problem here is not about how you build your query but about how you retrieve your data. FWIW, SQLAlchemy provides quite a lot of lower level SQL/Python integration that doesn't require the object mapping part. raw SQL is fine, until you have to dynamically build complex queries from user inputs and whatnot. This is where the low-level (ie: non-ORM) part of SQLAlchemy shines IMHO. -- http://mail.python.org/mailman/listinfo/python-list
Re: object-relational mappers
Bruno Desthuilliers schrieb: Jarek Zgoda a écrit : Bruno Desthuilliers napisał(a): Now my own experience is that whenever I tried this approach for anything non-trivial, I ended up building an ad-hoc, informally-specified bug-ridden slow implementation of half of SQLAlchemy. Which BTW is not strictly an ORM, but primarily an attempt at a better integration of SQL into Python. So while it may feel like learning the inner complexities of SQLALchemy (or Django's ORM which is not that bad either) is wasting brain cells, MVHO is that it's worth the time spent. But YMMV of course - IOW, do what works best for you. I like OR mappers, they save me lot of work. The problem is, all of them are very resource hungry, processing resultset of 300k objects one by one can effectively kill most of commodity systems. This is where raw SQL comes in handy. The problem here is not about how you build your query but about how you retrieve your data. FWIW, SQLAlchemy provides quite a lot of lower level SQL/Python integration that doesn't require the object mapping part. raw SQL is fine, until you have to dynamically build complex queries from user inputs and whatnot. This is where the low-level (ie: non-ORM) part of SQLAlchemy shines IMHO. The same can be said for SQLObjects SQLBuilder. Even if I ended up generating SQL for some query that didn't touch the ORM-layer, it helps tremendously to write e.g subqueries and such using python-objects instead of manipulating strings. They help keeping track of already referenced tables, spit out properly escaped syntax and so forth. Diez -- http://mail.python.org/mailman/listinfo/python-list
Re: object-relational mappers
Yes, webpy's db api can be used in stand-alone scripts if you want.
See below:
import web
db = web.database(dbn='mysql', db='northwind', user='root')
x = db.select('employees')
...
Another good thing is that, since queries return Storage objects
(similar to dictionaries), they are much more flexible.
Suppose that you get the results of a form sent via a POST method, and
you want to insert this data into your database.
You would simple write:
i = web.input()
db.insert('orders', **i)
So everything related to CRUD operations are is easy to do, without
having to mess with objects.
I think this sticks strictly to the KISS principle, keeping it simple,
with less overhead, less layers of abstraction and therefore, less
bugs and complications.
And it matchs perfectly webpy's philosofy for creating web apps.
Luis
On 3 abr, 11:06, Bruno Desthuilliers bruno.
[EMAIL PROTECTED] wrote:
Seems nice too in another way. Is that part independant of the rest of
the framework ? If so, I'll have to give it a try at least for admin
scripts.
--
http://mail.python.org/mailman/listinfo/python-list
Re: object-relational mappers
On 3 abr, 11:06, Bruno Desthuilliers bruno.
[EMAIL PROTECTED] wrote:
Luis M. González a écrit :
I have come to the same conclusion.
ORMs make easy things easier, but difficult things impossible...
Not my experience with SQLAlchemy. Ok, I still not had an occasion to
test it against stored procedures, but when it comes to complex queries,
it did the trick so far - and (warning: front-end developper
considerations ahead) happened to be much more usable than raw strings
to dynamically *build* the queries.
The best approach I've seen so far is webpy's (if we are talking of
web apps).
It isn't an ORM, it is just a way to make the database api easier to
use.
Queries don't return objects, they return something similar to
dictionaries, which can be used with dot notation ( for example,
result.name is equal to result['name'] ).
A simple select query would be db.select('customers') or
db.select('customers', name='John').
But you can also resort to plain sql as follows: db.query('select *
from customers where name = John').
Simple, effective and doesn't get in your way.
Seems nice too in another way. Is that part independant of the rest of
the framework ? If so, I'll have to give it a try at least for admin
scripts.
Yes, webpy's db api can be used in stand-alone scripts if you want.
See below:
import web
db = web.database(dbn='mysql', db='northwind', user='root')
x = db.select('employees')
for i in x:
print i.FirstName, i.LastName
...
Another good thing is that, since queries return Storage objects
(similar to dictionaries), they are much more flexible.
Suppose that you get the results of a form sent via a POST method, and
you want to insert this data into your database.
You would simple write:
i = web.input()
db.insert('orders', **i)
So everything related to CRUD operations are is easy to do, without
having to mess with objects.
I think this sticks strictly to the KISS principle, keeping it simple,
with less overhead, less layers of abstraction and therefore, less
bugs and complications.
And it matchs perfectly webpy's philosofy for creating web apps.
Luis
--
http://mail.python.org/mailman/listinfo/python-list
Re: object-relational mappers
On 2008-04-01 22:40, Aaron Watters wrote: I've been poking around the world of object-relational mappers and it inspired me to coin a corellary to the the famous quote on regular expressions: You have objects and a database: that's 2 problems. So: get an object-relational mapper: now you have 2**3 problems. That is to say I feel that they all make me learn so much about the internals and features of the O-R mapper itself that I would be better off rolling my own queries on an as-needed basis without wasting so many brain cells. comments? I fully agree :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Apr 03 2008) Python/Zope Consulting and Support ...http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 -- http://mail.python.org/mailman/listinfo/python-list
Re: object-relational mappers
hdante a écrit : On Apr 1, 5:40 pm, Aaron Watters [EMAIL PROTECTED] wrote: I've been poking around the world of object-relational mappers and it inspired me to coin a corellary to the the famous quote on regular expressions: You have objects and a database: that's 2 problems. So: get an object-relational mapper: now you have 2**3 problems. That is to say I feel that they all make me learn so much about the internals and features of the O-R mapper itself that I would be better off rolling my own queries on an as-needed basis without wasting so many brain cells. comments? Try Rails' ActiveRecord. Your problems should reduce to (lg lg 2)^(1/12). Correct me if I'm wrong, but IIRC ActiveRecord requires you use numeric auto_increment fields for primary key. As far as I'm concerned, this is a definitive no-no. Seriously, you'll forget there's a relational database below. Why on earth are you using a RDBMS if you don't want it ? I for one *do* care about using a *relational* database, and *don't* want to hide it away. What I don't want is to have to build my queries as raw strings. And that's where SQLAlchemy shines : it's not primarily an ORM, it's an higher-level Python/SQL integration tool that let you build your queries as Python objects (and also, eventually, build an ORM if you want to...). -- http://mail.python.org/mailman/listinfo/python-list
Re: object-relational mappers
Aaron Watters a écrit : I've been poking around the world of object-relational mappers and it inspired me to coin a corellary to the the famous quote on regular expressions: You have objects and a database: that's 2 problems. So: get an object-relational mapper: now you have 2**3 problems. That is to say I feel that they all make me learn so much about the internals and features of the O-R mapper itself that I would be better off rolling my own queries on an as-needed basis without wasting so many brain cells. comments? If you're ok with building your queries as raw string and handling your resultsets as lists of tuples, then you're right, don't waste you brain cells learning anything else than SQL and the DB-API. Now my own experience is that whenever I tried this approach for anything non-trivial, I ended up building an ad-hoc, informally-specified bug-ridden slow implementation of half of SQLAlchemy. Which BTW is not strictly an ORM, but primarily an attempt at a better integration of SQL into Python. So while it may feel like learning the inner complexities of SQLALchemy (or Django's ORM which is not that bad either) is wasting brain cells, MVHO is that it's worth the time spent. But YMMV of course - IOW, do what works best for you. -- http://mail.python.org/mailman/listinfo/python-list
Re: object-relational mappers
On Apr 2, 8:25 am, Bruno Desthuilliers bruno. [EMAIL PROTECTED] wrote: hdante a écrit : Try Rails' ActiveRecord. Your problems should reduce to (lg lg 2)^(1/12). Correct me if I'm wrong, but IIRC ActiveRecord requires you use numeric auto_increment fields for primary key. As far as I'm concerned, this is a definitive no-no. Why is that so bad ? But wait !, you cry. Shouldn't the primary key of my orders table be the order number or some other meaningful column ? Why use an artificial primary key such as id ? The reason is largely a practical one - the format of external data may change over time. (...) Normally, Active Record takes care of creating new primary key values for records that you create and add to the database - they'll be ascending integers (possibily with some gaps in the sequence). However, if you override the primary key column's name, you also take on the responsibility of setting the primary key to a unique value before you save a new row. -- AWDWR Seriously, you'll forget there's a relational database below. Why on earth are you using a RDBMS if you don't want it ? I for one *do* care about using a *relational* database, and *don't* want to hide it away. What I don't want is to have to build my queries as raw strings. And that's where SQLAlchemy shines : it's not primarily an ORM, it's an higher-level Python/SQL integration tool that let you build your queries as Python objects (and also, eventually, build an ORM if you want to...). Some object-relational mappers seek to eliminate the use of SQL entirely, hoping for object-oriented purity by forcing all queries through an OO layer. Active Record does not. It was built on the notion that SQL is neither dirty nor bad, just verbose in the trivial cases. (...) Therefore, you shouldn't feel guilty when you use find_by_sql to handle either performance bottlenecks or hard queries. Start out using the object-oriented interface for productivity and pleasure, and then dip beneath the surface for a close-to-the-metal experience when you need to do so. -- AWDWR PS. That's okay to use a RDBMS. What I don't want is to use two programming paradigms, especially, considering the object-relational impedance mismatch. -- http://mail.python.org/mailman/listinfo/python-list
Re: object-relational mappers
Try Rails' ActiveRecord. Your problems should reduce to (lg lg 2)^(1/12). python (log(log(2)))**(1.0/12.0) Traceback (most recent call last): File stdin, line 1, in ? ValueError: negative number cannot be raised to a fractional power So you are saying the problems will get really complex? :) Seriously, you'll forget there's a relational database below. (there are even intefaces for relational lists, trees, etc.) My experience with this sort of thing is that it is a bit like morphine. It can feel really good, and in emergencies it can save you a lot of pain. But if you use it too often and too seriously you end up with really big problems. -- Aaron Watters === http://www.xfeedme.com/nucular/pydistro.py/go?FREETEXT=mysterious+objects -- http://mail.python.org/mailman/listinfo/python-list
Re: object-relational mappers
On Apr 2, 10:50 am, Aaron Watters [EMAIL PROTECTED] wrote: Try Rails' ActiveRecord. Your problems should reduce to (lg lg 2)^(1/12). python (log(log(2)))**(1.0/12.0) Traceback (most recent call last): File stdin, line 1, in ? ValueError: negative number cannot be raised to a fractional power So you are saying the problems will get really complex? :) lg(x) == log_2(x) lg(lg(2))^(1/12) == 0. (fortunately I didn't write 3 lg's). :-P Seriously, you'll forget there's a relational database below. (there are even intefaces for relational lists, trees, etc.) My experience with this sort of thing is that it is a bit like morphine. It can feel really good, and in emergencies I don't have this much experience on either. ;-) it can save you a lot of pain. But if you use it too often and too seriously you end up with really big problems. -- Aaron Watters ===http://www.xfeedme.com/nucular/pydistro.py/go?FREETEXT=mysterious+obj... -- http://mail.python.org/mailman/listinfo/python-list
Re: object-relational mappers
On Apr 2, 8:25 am, hdante [EMAIL PROTECTED] wrote: On Apr 2, 8:25 am, Bruno Desthuilliers bruno. [EMAIL PROTECTED] wrote: hdante a écrit : Try Rails' ActiveRecord. Your problems should reduce to (lg lg 2)^(1/12). Correct me if I'm wrong, but IIRC ActiveRecord requires you use numeric auto_increment fields for primary key. As far as I'm concerned, this is a definitive no-no. Why is that so bad ? But wait !, you cry. Shouldn't the primary key of my orders table be the order number or some other meaningful column ? Why use an artificial primary key such as id ? The reason is largely a practical one - the format of external data may change over time. (...) Normally, Active Record takes care of creating new primary key values for records that you create and add to the database - they'll be ascending integers (possibily with some gaps in the sequence). However, if you override the primary key column's name, you also take on the responsibility of setting the primary key to a unique value before you save a new row. -- AWDWR Seriously, you'll forget there's a relational database below. Why on earth are you using a RDBMS if you don't want it ? I for one *do* care about using a *relational* database, and *don't* want to hide it away. What I don't want is to have to build my queries as raw strings. And that's where SQLAlchemy shines : it's not primarily an ORM, it's an higher-level Python/SQL integration tool that let you build your queries as Python objects (and also, eventually, build an ORM if you want to...). Some object-relational mappers seek to eliminate the use of SQL entirely, hoping for object-oriented purity by forcing all queries through an OO layer. Active Record does not. It was built on the notion that SQL is neither dirty nor bad, just verbose in the trivial cases. (...) Therefore, you shouldn't feel guilty when you use find_by_sql to handle either performance bottlenecks or hard queries. Start out using the object-oriented interface for productivity and pleasure, and then dip beneath the surface for a close-to-the-metal experience when you need to do so. -- AWDWR PS. That's okay to use a RDBMS. What I don't want is to use two programming paradigms, especially, considering the object-relational impedance mismatch. I think a shelf can accomplish everything a RDMS can. Just set up everything as a map from a real number, remove and extract at will (between numbers), and use XML tags. shelf[ 0.1 ]= 'data/', 'code code code' shelf[ 0.125 ]= 'name/', 'castironpi' shelf[ 0.05 ]= 'modifier/', 'oddly enough' -= data code code code /data name castironpi /name modifier oddly enough /modifier and shelf[ 0.1 ]= 'data/', 'code code code' shelf[ 0.125 ]= 'name', 'castironpi' shelf[ 0.05 ]= 'modifier', 'oddly enough' -= data code code code /data name castironpi modifier oddly enough /modifier /name Plus you can't have text and subnodes anyway. -- http://mail.python.org/mailman/listinfo/python-list
Re: object-relational mappers
On Apr 1, 1:40 pm, Aaron Watters [EMAIL PROTECTED] wrote: I've been poking around the world of object-relational mappers and it inspired me to coin a corellary to the the famous quote on regular expressions: You have objects and a database: that's 2 problems. So: get an object-relational mapper: now you have 2**3 problems. That is to say I feel that they all make me learn so much about the internals and features of the O-R mapper itself that I would be better off rolling my own queries on an as-needed basis without wasting so many brain cells. comments? -- Aaron Watters ===http://www.xfeedme.com/nucular/pydistro.py/go?FREETEXT=mild+exponenti... You're going to have to learn how any of the OR mappers work to get anything reasonable out of them, and you are going to need to commit and invest the time to learn how one works. I would argue that you should try making a prototype using one or two OR mappers (or just use SQLAlchemy/Elixir and be done with it) with your existing database and see which most efficiently does what you need it to. If you get to the point where the queries are getting too complex to reasonably manage as python code, then yeah, use raw SQL because that is what it's good for. Most OR mappers will allow you to sprinkle in raw SQL as needed. I think it's natural to be paralyzed by all the choices you have, but just start writing some code and go from there. -- http://mail.python.org/mailman/listinfo/python-list
Re: object-relational mappers
Aaron Watters [EMAIL PROTECTED] wrote: I've been poking around the world of object-relational mappers and it inspired me to coin a corellary to the the famous quote on regular expressions: You have objects and a database: that's 2 problems. So: get an object-relational mapper: now you have 2**3 problems. That is to say I feel that they all make me learn so much about the internals and features of the O-R mapper itself that I would be better off rolling my own queries on an as-needed basis without wasting so many brain cells. That is the conclusion I have come to. When a difficult question comes up, you end up having to know the exact requirements and behaviour of the underlying database anyway. Then once you know what sequence of commands you need to be issued, you have to figure out how to persuade the ORM to do it (and not something similar but subtly wrong). At this stage it's getting in your way. -M- -- http://mail.python.org/mailman/listinfo/python-list
Re: object-relational mappers
On Apr 1, 5:40 pm, Aaron Watters [EMAIL PROTECTED] wrote: I've been poking around the world of object-relational mappers and it inspired me to coin a corellary to the the famous quote on regular expressions: You have objects and a database: that's 2 problems. So: get an object-relational mapper: now you have 2**3 problems. That is to say I feel that they all make me learn so much about the internals and features of the O-R mapper itself that I would be better off rolling my own queries on an as-needed basis without wasting so many brain cells. comments? Try Rails' ActiveRecord. Your problems should reduce to (lg lg 2)^(1/12). Seriously, you'll forget there's a relational database below. (there are even intefaces for relational lists, trees, etc.) I won't post a code sample here, it would be heretic. :-) -- Aaron Watters ===http://www.xfeedme.com/nucular/pydistro.py/go?FREETEXT=mild+exponenti... -- http://mail.python.org/mailman/listinfo/python-list
