This ORM looks interesting



How else were you planning on publishing your code?

Ummm, not sure. I honestly just thought about releasing a solution that a client would be happy with.

For publishing code, I'm not going to publish absolutely everything, such as my template engine, etc. However, anything I write for the competition itself, I'd be happy to put up on a server accessible via FTP & HTTP for everyone, if that helps any. Would be easy to develop in a quick exception so any code I write for it would be automatically saved to another directory, which everyone can access. Please note, that would only be for code I write for this project alone, and not the infrastructure itself.
 
I don't think this needs to be taken as serious as it is being taken right now. We pick a time period, pick a project type, and hack away. Kiopa, however you want to share the code is fine, no use in us trying to convince you to use something. We'll use Github because it's quick and easy and we already use it.

I think we can all agree that a simple rss reader is basically CRUD + background worker/CRON, no matter what language or framework we use, it shouldn't take much more than like 2 hours for a competent coder to slap together. That's why I suggested we pick something like 8 hours for the project, with the minimum app requirements, and you are free to add in whatever extra features you want. Custom analytics, social recommendations, cookie stuffing, whatever...I think that's where the variety and fun will be in this.
 
Ok, sounds good to me. However you guys want to do things. Well, except for the Github exception. I'm not doing Github, although happy to make any code available that I write for this.

I actually want to do this now though. Mainly just to prove to myself that what I'm using stands up to whatever you yungins' are using these days.
 
I really like this, (I just read about .show(), and sql debug is on):

Code:
In [8]: orm.SearchEngine.select(lambda se: orm.Category[1] in se.categories).show()
SELECT "se"."id", "se"."name", "se"."locale"
FROM "searchengine" "se"
WHERE %(p1)s IN (
    SELECT "t-1"."category"
    FROM "category_searchengine" "t-1"
    WHERE "se"."id" = "t-1"."searchengine"
    )
{'p1':1}

id|name  |locale
--+------+------
1 |google|en-us
2 |bing  |en-us
3 |google|en-uk
4 |bing  |en-uk
5 |google|en-ca
6 |bing  |en-ca
 
heh, prime example of what I mean actually. :)

You shouldn't be using SQL queries like that (WHERE id IN (select ... )), and the practice is heavily discouraged. Try that against larger tables with several million rows and a heavy traffic load, and it'll grind your database (and server) to a halt. Queries will start taking 2+ seconds, locking the tables in the process, backing up other queries, until it gets to a point where queries are taking 60+ seconds and Apache/Nginx are timing out before the request completes.

Instead, it should be something like:

Code:
SELECT se.id, se.name, se.locale FROM searchengine AS se, category_searchengine AS cat WHERE se.id = cat.searchengine AND se.p1s = cat.category;

See, don't trust ORMs so readily. :)
 
This is a one-to-many query:

Code:
In [27]: orm.Keyword.select(lambda k: k.category.id == 1).show()
SELECT "k"."id", "k"."keyword", "k"."category"
FROM "keyword" "k"
WHERE "k"."category" = 1
or to get data from from relationship:

Code:
In [32]: orm.select((k, k.category.name) for k in orm.Keyword if k.category.id == 1).show()
SELECT DISTINCT "k"."id", "category-1"."name"
FROM "keyword" "k", "category" "category-1"
WHERE "k"."category" = 1
  AND "k"."category" = "category-1"."id"
 
And maybe this is better:

Code:
In [7]: set(orm.Category[1].searchengines)
SELECT "T1"."searchengine"
FROM "category_searchengine" "T1"
WHERE "T1"."category" = %(p1)s
{'p1':1}

Out[7]:
set([SearchEngine[1],
     SearchEngine[3],
     SearchEngine[5],
     SearchEngine[2],
     SearchEngine[4],
     SearchEngine[6]])
 
This is a one-to-many query:

Code:
In [27]: orm.Keyword.select(lambda k: k.category.id == 1).show()
SELECT "k"."id", "k"."keyword", "k"."category"
FROM "keyword" "k"
WHERE "k"."category" = 1

No, that's a one-to-nothing relationship. There's only one table involved.

or to get data from from relationship:
Code:
In [32]: orm.select((k, k.category.name) for k in orm.Keyword if k.category.id == 1).show()
SELECT DISTINCT "k"."id", "category-1"."name"
FROM "keyword" "k", "category" "category-1"
WHERE "k"."category" = 1
  AND "k"."category" = "category-1"."id"

That's a one-to-many relationship.

And maybe this is better:

Code:
In [7]: set(orm.Category[1].searchengines)
SELECT "T1"."searchengine"
FROM "category_searchengine" "T1"
WHERE "T1"."category" = %(p1)s
{'p1':1}

Again, that's a one-to-nothing relationship, as there's only one table involved. Here:

one-to-many:

Code:
SELECT payment.id, acct.id, acct.name FROM accounts AS acct, payments AS payment WHERE acct.id = 4 AND payment.userid = acct.id AND payment.status = 'approved';
many-to-many:

Code:
SELECT payment.id, acct.id, acct.name FROM accounts AS acct, payments AS payment WHERE acct.id = payment.userid AND payment.status = 'approved';
Regardless, you shouldn't be putting select sub-queries within "IN ( )" statements, as it's very inefficient, and there's no reason to do so. heh, I actually cost a client about $5k in new servers and server admin fees once because I wasn't aware of that. Turns out all I needed to do was switch out the "IN ()" statements with proper ones, and everything began working like clockwork.
 
I worked it out, with a little help from a guy helping me out with a project:

Code:
In [4]: orm.select(c.searchengines for c in orm.Category if c.name.startswith('De'))[:]
SELECT DISTINCT "searchengine-1"."id", "searchengine-1"."name", "searchengine-1"."locale"
FROM "category" "c", "category_searchengine" "t-1", "searchengine" "searchengine-1"
WHERE "c"."name" LIKE 'De%%'
  AND "c"."id" = "t-1"."category"
  AND "t-1"."searchengine" = "searchengine-1"."id"
 
Ok, so "code off" on the 30th or so then? I honestly want to do this now, because I want to see where I stand. I generally have my head buried within my own code, and don't keep up much with latest practices. So I'd like to see if what I have stands up to your guys' latest methodologies.

Maybe I know what I'm doing, and maybe I'll make an ass out of myself. Not sure yet. So far, there's just myself, mattseh and dchuk, right? Anyone else in?
 
30th-ish sounds fine by me.

I'd love if Mahzkrieg participated, also if there are any golang users, that'd be very interesting to see.
 
^^ LOL.

Another reason not to trust ORMs. Watch the SQL statement he pulls down at 2:15. He has:

Code:
SELECT avg("o"."total_price") FROM "Orders"."o" WHERE CAST(SUBSTR("o"."date_created", 1, 4) AS integer) = 2012
Sloopy, sloppy. Find me one DBA who says the above is a good SQL statement. Should be something like:

Code:
SELECT avg(total_price) FROM orders WHERE YEAR(date_created) = 2012
Except these Pony ORM apparently doesn't distinguish between date and varchar columns, so it assumes varchar, and uses the ridiculous cast(substr()) syntax. This is very, VERY basic stuff, and if the ORM can't get this right, then what happens when it comes across a complex SQL statement? Pffft...
 
It's not sloppy, it's not repeating yourself, the ORM is taking code structures, and, in a predictable way, converting them to database table structures.

During development, it's easy to change the structure in the code, while being able to easily revert to a previous structure (by reverting git commits / switching branches) and then by running 1 script, creating the entire database from scratch.

I have never done this, but I imagine that for certain projects, being able to dynamically create ORM models (classes), and therefore database tables could be advantageous.

I'm pretty sure that everyone in this discussion knows SQL to a decent level, it doesn't necessarily mean we should use it whenever interacting with a database.

I use ORM for basic stuff in PHP and it makes life 100x nicer.

PHP:
$model = new Model();
$model->some_column = 'value 1';
$model->save();

That kind of thing (that's exactly what it looks like as well), but for anything requiring joins or anything more than a select from a single table I still like writing the SQL.