how are they at being fried though?
That kills them,but you better hope it's not the kind of bastards* who produce a poison to keep other multicellular organisms like you off their munchies, because the poison will survive the frying no sweat.
*and it’s always them
the swine, i could have 'em
in a fight though
Jonas, do you rember when you said
you came up with an idiot proof way to prevent double posting.
It appears I broked it.
Two ways to prevent double posts
1] Before inserting a new post, query for the last post by the user, and if the subject and body matches, ignore it
- or -
2] Use AJAX and disable the submit button on submit
I have an implementation of option 1 in test at the moment.
Whilst it means an extra database query per post, I prefer it to the ajax option as it works even for people who disable javascript or don't have it available on their browser (phone/pdas/etc).
option 1 seems likely to be a bit hard on the server to me
though I'm not particularly good at optimising sql stuff, I'm under the impression querying long strings isn't terribly efficient
Well, you're not doing the querying in the database,
merely doing a simple select to get the most recent post by that user.
You then do the string comparison in your code, which should be relatively lightweight.
Admittedly, there's will be a performance hit, but I don't think it's unwarranted. The whole site and database structure is geared up to minimise impact when reading, as that's what is done most often.
I cache my board data and invalidate it if and when a post is made or updated
That way a simple F5 typically doesn't touch the database. I can't remember the perf increase but I think something like 10x faster in terms of fetching data. I've gone for [2] so double posts are impossible too
I haven't even begun to look seriously at caching yet.
The django framework has some pretty hefty caching mechanisms in it, and I'll make use of those for some areas of the site as they're no-effort to me solutions.
For the board itself, I like your idea of invalidating the cache when a post is modified or created, and I know I can hook into the framework's cache structure to provide that sort of functionality, so it's something I'll look at.
Currently, there's a ratio of about 25:1 with reads to writes, so an approach like that should yield reasonable benefits.
Incidentally, I was comparing database performance between this codebase and the old one,
and it seems like I've made things 10* times better already, which is pleasing.
*9.873 to be precise.
It's just a shame you're persisting with php
unless I've very much mistaken, it's phython and django
rather than php
I'm not.
It's all in python now!
PHP is an abortion and should be stuck in a shallow grave.
Sorry (both) I realised my mistake on the way home
I meant python of course. I did also change my mind on the way home since python is quite a sweet language. django looks alright but the whole approach is fundamentally broken I think. It does do exactly what you need, but I think you'll find it hard to expand beyond a simple web app
Basically I think it should have a service based architecture, but I've probably been reading too many WCF books
I've come to a similar conclusion regarding django
as I've been considering using it for a work thing but think it's a bit limited for what I'm after
that said,
it seems it's quite easy to write your own framework in python so there's no need to use django if it doesn't suit
I'm all for doing it myself but that looks like a lot of hard work to me
It's a pity you refuse to come over to the dark side. You'll find all the best language features of python are already in C# (ie lambdas, anonymous types, closures etc), and the environment is much easier to get to grips with. Of course you could try IronPython too, which is faster than Python (which itself if a bit of a dog performance wise -- though better than Ruby)
Shame really
ah, yes
I hadn't considered using the last post by the user to check against rather.
I was imagining it checking the whole db for duplicates.
Nah, that way madness lies.
And certainly nothing like that was responsible for crippling the database under the old code base. Oh no.
I didn't say I'd implemented it.
;-)
depends on the type of spores.