This ORM looks interesting
- Thread starter mattseh
- Start date
You and me both, bro.
The funny thing about WF's development subforum is that the few of us that actually frequent this subforum just have different tech on our plates. Except for rage9 who's still busy building his own plate.
It's really unfortunate since we all enjoy building the same sort of stuff. Maybe one day we'll all converge onto the same stack and have a real circlejerk. Until then all we've got are a bunch of one-man peep shows.
Anyways,
I had to look up what Python generators are, but I like Pony's deliberate effort to compose sql out of them.
Lots to glean from the HN comments: https://news.ycombinator.com/item?id=5575277
Someone provided this example.
Plain ol Python:
Code:
list(o for o in Item if o.price>3)
Code:
select(o for o in Item if o.price>3)Another example:
Can you provide an example of the Python ORM you currently use? It's hard to appreciate this ORM without seeing how people are otherwise writing sql with Python.
To really get the crickets chirping, lemme share Clojure's main ORM: sqlkorma
Rails' Active Record ORM is so bad that you can't even write the above query without using SQL strings (or the lower-level lib that sits behind AR).
Django's ORM also sounds poor given the amount of people that immediate swap it out for SQLAlchemy.
Rails' Active Record ORM is so bad that you can't even write the above query without using SQL strings (or the lower-level lib that sits behind AR).
Django's ORM also sounds poor given the amount of people that immediate swap it out for SQLAlchemy.
Rage9 uses flask now, after I convinced him. He'll never admit this though.
Generators in general are really cool. Here's a common one that I use:
Not instantly ballooning the process size to gigabytes, as a list would do with lots of data, is neat.
The plain old python example you gave would actually convert it straight away to a list,
is completely valid.
I have used Django's ORM in the past, it is hard to do anything interesting with it, but I like how simple it is to create models. It's also a pain to use the models outside of the webapp cleanly. Not being able to pass expressions like filter(x < 5) sucks.
SQLAlchemy was my goto before pony, I have lots of it in production. It's really freaking verbose, but I haven't seen it do anything stupid.
Pony's main advantages IMO are the Django-like model definitions and clean query syntax.
The parsing of generator expressions into an abstract syntax tree is really smart.
I'd never heard complaints about AR before, maybe that's just most rubyists for you
Re: the echo chamber, I think there's 3 main groups on here:
1. Noobs struggling with simple WP / HTML problems (nothing wrong with that, we all start somewhere)
2. The lazy, who are happy with sub-optimal technologies and processes, and don't want to expand their skills.
3. The smart, who keep to themselves / private groups and get stuff done.
Generators in general are really cool. Here's a common one that I use:
Code:
urls = (l.strip() for l in open('urls.txt') if len(l.strip()))Not instantly ballooning the process size to gigabytes, as a list would do with lots of data, is neat.
The plain old python example you gave would actually convert it straight away to a list,
Code:
(o for o in Item if o.price>3)I have used Django's ORM in the past, it is hard to do anything interesting with it, but I like how simple it is to create models. It's also a pain to use the models outside of the webapp cleanly. Not being able to pass expressions like filter(x < 5) sucks.
SQLAlchemy was my goto before pony, I have lots of it in production. It's really freaking verbose, but I haven't seen it do anything stupid.
Pony's main advantages IMO are the Django-like model definitions and clean query syntax.
The parsing of generator expressions into an abstract syntax tree is really smart.
I'd never heard complaints about AR before, maybe that's just most rubyists for you
Re: the echo chamber, I think there's 3 main groups on here:
1. Noobs struggling with simple WP / HTML problems (nothing wrong with that, we all start somewhere)
2. The lazy, who are happy with sub-optimal technologies and processes, and don't want to expand their skills.
3. The smart, who keep to themselves / private groups and get stuff done.
I just spent roughly one working day switching an existing project-in-progress over to pony. Around 30 minutes to adapt the models, then just going through and rewriting queries.
I now have a lot less code, it is much easier to understand, and am making faster progress on the project (i was procrastinating hard on writing complex SQLAlchemy queries)
I now have a lot less code, it is much easier to understand, and am making faster progress on the project (i was procrastinating hard on writing complex SQLAlchemy queries)
I noticed this on HN a few days ago too but aside from the difference in syntax, I couldn't see much of a benefit over SQLAlchemy
I'm assuming that I've missed the point though?
With it being a commercial product and not having the benefits of something like Alembic for auto migrations, it would need to be pretty special for me to turn my back on SQLAlchemy even though I've got relatively little experience with it.
I'm assuming that I've missed the point though?
With it being a commercial product and not having the benefits of something like Alembic for auto migrations, it would need to be pretty special for me to turn my back on SQLAlchemy even though I've got relatively little experience with it.
It just seems cleaner to me. Migrations are a pain point, which they claim to be working on. SQLAlchemy seemed to get in my way.
Also, I really like generators.
Sorry, but no. I don't want anything creating the database schemas for me. Can't see how that would end well.
DBIx::Class
Searches can be chained like in jQuery:
In the end will produce a single SQL statement that reflects your entire chain.
Searches can be chained like in jQuery:
In the end will produce a single SQL statement that reflects your entire chain.
^^ I've never understood the desire for developers to use this type of thing. Why not just use SQL?
Isn't that easier than messing around with code like above? Not to mention when you get into more complex queries while displaying statistics and things, then using SQL is without question better.
Code:
SELECT * FROM table WHERE name = 'John' ORDER BY ageIsn't that easier than messing around with code like above? Not to mention when you get into more complex queries while displaying statistics and things, then using SQL is without question better.
it (redbean) doesn't guess...you are explicitly controlling it via a naming convention.
Just took a closer look, and it appears you get to choose the column names via object properties, but that's about it. Maybe I'm wrong, but doesn't seem like there's anything for column types, primary keys, foreign keys, cascading, auto increments, etc
Things like this are good if you're just doing really basic stuff like a contact form, or some guestbook, or category management of some kind, or whatever. They're horrible for the development of any actual systems though. Plus I'd just simply never want something writing the database schemas for me. If a developer ever has to play around in my software, the table structure helps let them know what's going on. Having every column as a VARCHAR(255) just really isn't going to work.
I don't know, don't mind me. I just have a disdain for most of the ORMs I see, as people believe it makes things so much easier, while I look at it and think it'd only make my job much more difficult, while delivering lower quality software.
Then again, I get made fun of on here for making notes in Homesite still, so fuck it, who knows...
It does most of that. Foreign keys, for example, are driven by a naming convention (see Schema | RedBeanPHP). Column types are "automagic", but there's a setMeta method if you want explicit casting to a datatype. A primary key is required, and redbean isn't very flexible about naming it.
I've been using Elixir with SQLAlchemy. The project I'm on now has a mix of pre-existing tables and tables I let the framework create. I probably didn't need Elixir at this point, because anything with some degree of complexity, I have been just using the SQLAlchemy functions (I'm still learning both).
It's getting harder and harder to get away with using raw queries. At a minimum, you should use prepared atatements to help protect against injection exploits. Once someone gets to that point, it is very tempting to write a library for it, or seek out something already built.
Except when I do, and have done for a while. Pretty sure I've even made a drunken thread about it.
No matter how many times I say it though, no one seems to believe it.
For the last time, I was a moron. Live and learn. Although I will say it drives me nuts how you post so many different new techs, how can you possibly keep up with them all?
Also:
