Previous Entry Share Next Entry
Note to self..

So I've got the Entry class nailed in my PHP, with the relevant constructors to populate it with a level of data appropriate to the database resource requirements of the application.

Thinking that it needs to contain a User class object, as will all future Comment objects, because that really is the most logical way to access userpic and realname data items, not to mention it means I can write a single instance of the ->base_url() code that will be needed for linking to stuff.

Speed tests are actually really easy, because I can pull a hundred entries, and populate the objects in turn, then test for speed.. There's entry data, comment data and user data that'll need to be added, and I need to test whether a join is quicker, or if three separate calls per entry are best.

For some applications like search, pre-populating with a query should be enough, with an "expand" link that, if necessary, will enrich an individual entry via an Ajax call with the full data. That way, you call one query, create 100 objects with no database calls in them, and then let the user click one or two and generate three calls each, so seven database calls in total. Rather than pre-populating all of them. That's what I mean about appropriate levels of data at instantiation.

Incremental levels of data should also work for a single screen interface to multiple levels of data. A container can contain multiple entries, but if you click the right link against a single entry, all the other entries will vanish, your selected entry will be promoted to the main focus, and an Ajax call will drag in the required comment data.

Theoretically at the time of comment population it should be possible to check whether there are any orphaned pids with no cids, and run a script that grabs the comment hash from LJ at least to tie those comments into threads, even if the content doesn't get loaded.

So all of that means that that you'd load a single page of entries, either as search results (in which case they'll have limited data attached, nothing more than exists within the entries table) or just a "Most popular" or "Most recent" snapshot, and wouldn't need a full page refresh to load the comments attached to them.

And of course once that's working nicely, then that means that my entry search, comment search and user search features will be a hell of a lot easier to code, and create neat little links between - for example, rendering (correctly) a user's last entry on their profile page, with that ajax promotion stuff working, means that there would be far fewer database hits than otherwise, and quicker loading times for core information. Which is nice.

So, next steps.. Actually update the search function to use the Entry class, which shouldn't be hard since search was one of the test interfaces that I bolted onto the class... I figure that the comment and user classes can wait until the search is at least done, so new search page using new layout and new class. Onward!

  • 1
Yeah, you should get on that.

I will give you $10 if you can actually work out how any of what I'm talking about works :oP

I will not prostitute my brain for you!

Just other parts, then?

Not to you or James, but for someone else, I'm sure a negotiation could be made. :D

Incidentally, most of that made sense to me, but I don't speak PHP, and my AJAX knowledge is non-existent :)

  • 1

Log in

No account? Create an account