Active record pattern

[Jeremy]

Who here mentioned XF was written in Rails? Oh wait your confused not sure if you don't understand the benefits or mean something else entirely.

We're simply talking about using the AR pattern in xenforo. The AR pattern isn't for rails only, it can be implement in other languages and has been done in PHP e.g.Yii framework.

Actually, it appears you aren't reading your own thread. The post right above mine (of which ibnesayeed corrected) talks about AR improvements in Ruby on Rails. So, no, I'm not that confused. I know exactly what's going on in this thread. And frankly, if Kier & Mike both say that its not best for XenForo, I'm perfectly fine with it. But just to be sure, I'll do some "research" to back them up later tonight.

 

[Jeremy]

Who here mentioned XF was written in Rails? Oh wait your confused not sure if you don't understand the benefits or mean something else entirely.

We're simply talking about using the AR pattern in xenforo. The AR pattern isn't for rails only, it can be implement in other languages and has been done in PHP e.g.Yii framework.

Well, if I'm reading that page right (and I'm pretty sure I'm not entirely off), each database table = 1 object. If I display 25 posts/page, that means I create 25 post objects. Combine that with forum infromation, templates, alerts, messages, etc., that memory overhead could be potentially huge. And unless you have some type of proper PHP caching in the mix, that is multiplied exponentially as each user enters a page... Which in turn strains on the server, which in turn can hurt your site. See, I'm with Kier.

 

[ibnesayeed]

Actually, it appears you aren't reading your own thread. The post right above mine (of which ibnesayeed corrected) talks about AR improvements in Ruby on Rails. So, no, I'm not that confused. I know exactly what's going on in this thread. And frankly, if Kier & Mike both say that its not best for XenForo, I'm perfectly fine with it. But just to be sure, I'll do some "research" to back them up later tonight.

Already having an opinion and then doing some research for collecting other opinions and proofs to empower that opinion is one way. Not being biased and looking for all sorts of opinions, reports, benchmarks and analysis to find out positives and negatives about the object in observation is another approach.

There is nothing like perfect/best!

 

[Jeremy]

Already having an opinion and then doing some research for collecting other opinions and proofs to empower that opinion is one way. Not being biased and looking for all sorts of opinions, reports, benchmarks and analysis to find out positives and negatives about the object in observation is another approach.

There is nothing like perfect/best!

OK my research was strictly the Wikipedia article he linked. But the basic idea is one object to one row. I can imagine quite a few issues with things like this.

 

[ibnesayeed]

Well, if I'm reading that page right (and I'm pretty sure I'm not entirely off), each database table = 1 object. If I display 25 posts/page, that means I create 25 post objects. Combine that with forum infromation, templates, alerts, messages, etc., that memory overhead could be potentially huge. And unless you have some type of proper PHP caching in the mix, that is multiplied exponentially as each user enters a page... Which in turn strains on the server, which in turn can hurt your site. See, I'm with Kier.

db table == class (in disk)
one row result of record == one object (in memory)
multiple rows in the result set == an array of multiple objects (in memory)

All the memory overhead you mentioned above remain the same no matter ORM (Object Relational Mapping) is used or not. Because, when you don't use ORM, you keep result set or cursor in memory. In case of ORM, that is converted in the (array of) object(s). Indeed, there is little memory overhead when it is converted into the object. Also, there is some time overhead as well. But, this is the cost of getting additional flexibility, ease of programming and other benefits that we get when we use ORM.

 

[Jeremy]

db table == class (in disk)
one row result of record == one object (in memory)
multiple rows in the result set == an array of multiple objects (in memory)

All the memory overhead you mentioned above remain the same no matter ORM (Object Relational Mapping) is used or not. Because, when you don't use ORM, you keep result set or cursor in memory. In case of ORM, that is converted in the (array of) object(s). Indeed, there is little memory overhead when it is converted into the object. Also, there is some time overhead as well. But, this is the cost of getting additional flexibility, ease of programming and other benefits that we get when we use ORM.

This may be practical if you can share objects between visits, and have full memory of the server at your hands, but when you start to look at the users of XenForo, many are not on Dedicated servers. How can you accomplish a valid working software when you start storing large amounts of data in memory? I'm still seeing a lot of cons and not a lot of pros. No matter how you spin it. The AR structure could be valuable and useful within a computer based setting wherey ou have one user, with oone machine and all its resources.

 

[Forsaken]

Don't get why anyone would wish to suggest something that would increase the memory overhead of a forum even more than it already is.

 

[Onimua]

db table == class (in disk)
one row result of record == one object (in memory)
multiple rows in the result set == an array of multiple objects (in memory)

All the memory overhead you mentioned above remain the same no matter ORM (Object Relational Mapping) is used or not. Because, when you don't use ORM, you keep result set or cursor in memory. In case of ORM, that is converted in the (array of) object(s). Indeed, there is little memory overhead when it is converted into the object. Also, there is some time overhead as well. But, this is the cost of getting additional flexibility, ease of programming and other benefits that we get when we use ORM.

A little here and there adds up, especially for busy sites, and for shared hosting servers they need as little memory overhead as possible. Adding in time overhead doesn't sound very fun for the end-user either, not when a user expects things to happen quickly whenever they perform an action. Generally speaking, that sounds like reasons not to do it.

How is this proposed "flexibility and ease of programming" different than what is currently in XenForo now?

 

[Sniper]

Actually, it appears you aren't reading your own thread. The post right above mine (of which ibnesayeed corrected) talks about AR improvements in Ruby on Rails. So, no, I'm not that confused. I know exactly what's going on in this thread. And frankly, if Kier & Mike both say that its not best for XenForo, I'm perfectly fine with it. But just to be sure, I'll do some "research" to back them up later tonight.

Please point me to where it mentions Xenforo uses Rails? He used Rails as reference which you obviously didn't get. Mike and Kier are gods! I see, haha

Its all down to architecture (I don't know how many times I've had to say that), If you think EVERY object within Xenforo needs to use AR, then your wrong! I simply asked why not? I got back a lame answer back from Kier! If they did indeed research where is it? Perhaps it was mainly because they rushed XF and wanted to keep the structure similar to vBulletin, why break something that works, huh?

 

[Jeremy]

Please point me to where it mentions Xenforo uses Rails? Mike and Kier are gods! I see, haha.

A) Where the hell are you seeing that I said Mike and Kier are gods. In all actuality, you are the only person I have seen specifically mention them being gods. I do not doubt that they are amazingly talented programmers, but I never have elevated them to gods.
B) The entire post was about Ruby on Rails. I failed to see the benefit of discussing how Ruby on Rails improvements had any pertinence to why AR should be implemented in XenForo at all.
C) ibesayeed stated he was using it as an example of how it can improve is utilized correctly.

Its all down to architecture (I don't know how many times I've had to say that), If you think EVERY object within Xenforo needs to use AR, then your wrong! I simply asked why not? I got back a lame answer back! If they did indeed research where is it? Perhaps it was mainly because they rushed XF and wanted to keep the structure similar to vBulletin, why break something that works, huh?

XenForo isn't rushed. The quality of the product proves that. And I'm a computer science student and I just took and passed two different architecture classes, so you can stop acting as if I'm an idiot. The basic idea is to radically change the structure of XenForo (no matter if its similar to vB, IPB, phpBB, I don't care) to something that can create a lot of overhead for users and problems on shared servers with low memory constraints. Why would Likes being handled as AR when the system they have implemented is extendable and works beautifully? I am still failing to see why the structure they have created provides so many cons that could be fixed by AR.

To implement AR I would see the need to persistently keep these records so they can be shared per visit, which means a proper PHP caching software needs to be installed on the server and configured correctly. Tell me shared hosts are willing to allow you access to root (on a basic non-VPS+ plan) to install and configure this. Plus, tell me one non-experienced administrator who is capable of doing this without quite a bit of hand-holding to get a piece of forum software installed.

And for that matter, if its all down to architecture (of which you so kindly remind us), why didn't they just choose to abstract everything under the sun under mounds of query builders, classes, and other methods so that we can morph XenForo into whatever database structure we want, whatever LANGUAGE we want, and whatever architecture we want. Developers of software don't need to justify every little detail with mounds of research. I can see myself that the architecture would require more physical memory than the current structure (talking about RAM) without the need for mounds of research. This is a multi-user environment that can be run in low-memory shared servers. Keep that architecture in mind.

 

[Danny.VBT]

Please point me to where it mentions Xenforo uses Rails? Mike and Kier are gods! I see, haha

Its all down to architecture (I don't know how many times I've had to say that), If you think EVERY object within Xenforo needs to use AR, then your wrong! I simply asked why not? I got back a lame answer back from Kier! If they did indeed research where is it? Perhaps it was mainly because they rushed XF and wanted to keep the structure similar to vBulletin, why break something that works, huh?

The question should not be why not Active Record, it should be why Active Record.

I personally think Mike gave more than a sufficient answer here. Why over-engineer when its not necessary and will cause more headaches than solutions?

And DSA pattens should be decided based upon complexity of domain logic, not "additional flexibility," "ease of programming," or that Active Record is neat sounding buzz word atm.

 

[Sniper]

Assume what you like. I don't care if you took 100 classes, it doesn't mean I can not challenge someones thoughts! I purely say rushed because how similar it is to vBulletin, though that was bound to happen! Sorry but AR doesn't need to persists across requests! Even NOW if you wanted to scale xenforo, you'd need to use caching e.g. something like Varnish Not matter how fast you make your application, parts or even full pages will need to be cached if you really want to scale.

 

[Onimua]

Assume what you like. I don't care if you took 100 classes, it doesn't mean I can not challenge someones thoughts! I purely say rushed because how similar it is to vBulletin, though that was bound to happen! Sorry but AR doesn't need to persists across requests! Even NOW if you wanted to scale xenforo, you'd need to use caching e.g. something like Varnish Not matter how fast you make your application, parts or even full pages will need to be cached if you really want to scale.

So... caching is something would should avoid at all costs?

 

[Sniper]

lol Caching is need in every application if you want to scale!

Don't get be wrong, every one had valid arguments, but no one has yet to give me proof. Kier simply based it on reputation...

Feel free to prove me wrong.

 

[Bob]

lol Caching is need in every application if you want to scale!

Don't get be wrong, every one had valid arguments, but no one has yet to give me proof. Kier simply based it on reputation...

Feel free to prove me wrong.

Is this a contest now? Does the winner get a cookie?

 

[Jeremy]

Assume what you like. I don't care if you took 100 classes, it doesn't mean I can not challenge someones thoughts! I purely say rushed because how similar it is to vBulletin, though that was bound to happen! Sorry but AR doesn't need to persists across requests! Even NOW if you wanted to scale xenforo, you'd need to use caching e.g. something like Varnish Not matter how fast you make your application, parts or even full pages will need to be cached if you really want to scale.

For one, the one class was all about data structures (so AR fits right in) and the hidden costs: memory, speed, and usability. I see AR failing in a few of those methods. The underlying architecture is far from vBulletin, in my opinion. I didn't say not to challenge thoughts, but put some thought into what you're asking. And XenForo scales much better than I can imagine with a lot of concurrent users. If I recall, there aren't a massive amount of memory usage. I just opened up my local test-bed using v1.0.1 and it uses 12 queries on the index with a total memory usage of just over 7 MB. Now, lets start adding in a bunch of objects for likes, etc. It grows. I don't care if its "small," its still larger than it is. Add several hundred users, on a shared server. Houston, we've got a problem. XenForo works out of the box. More advanced sites most likely have someone knowledgeable enough to tweak a VPS or dedicated server to run their site to the optimum state. If you're one of them, congratulations. Tweak away. However, for those administrators who don't have the know how, hardware, or software, why make the software harder for them to use or set up? I'm with Danny here, provide me some reasons (and I mean solid reasons... maybe even some research. Although, so far your proven research as to why to implement it seems to be nothing more than Wikipedia.) into WHY Kier and Mike should spend development time implementing this and we'll talk about it.

 

[Jeremy]

Don't get be wrong, every one had valid arguments, but no one has yet to give me proof. Kier simply based it on reputation...

Feel free to prove me wrong.

Feel free to prove us wrong.

 

[Sniper]

@bobster65 unless you have something constructive to say, I kindly ask please dont post! Its opinions here nothing else!

 

[Jeremy]

@bobster65 unless you have something constructive to say, I kindly ask please dont post! Its opinions here nothing else!

We kindly ask you to provide constructive criticism to our counter arguments with proof. You are demanding Kier give it, we are now demanding you give it.

 

[Sniper]

@King Kovifor looks like your assuming EVERYTHING will use AR. XF already caches likes, so it doesn't have to fetch every time....same thing could be done via AR.