Active record pattern

No it does not! It simply provides an object-oriented interface to database tables, so not even close to AR patterm. I recommend you actually read the above wiki or do a bit more research.

If XF ever does, it will greatly reduce the amount of repeated code, even the Zend framework doesn't support the AR pattern.
 
No it does not! It simply provides an object-oriented interface to database tables, so not even close to AR patterm. I recommend you actually read the above wiki or do a bit more research.

If XF ever does, it will greatly reduce the amount of repeated code, even the Zend framework doesn't support the AR pattern.

Now now, play nice LOL

There has been a proposal for AR to be implemented in the zend framework by the looks of it.
http://framework.zend.com/wiki/display/ZFPROP/Zend_Db_ActiveRecord

If Im honest I cant see how it would reduce repeated code however. I dont vouch for being an expert by a long, however could you not just wrap the updating of tables within a class anyway? Or am I missing the point?
 
I do actually like the ORM concept, but "hydration" is always a concern. There are definite performance concerns; as you can see, many of our queries span multiple data types, with a lot of conditions of how to do those joins. I wouldn't be happy splitting those 1:1 relationship joins out to separate queries, nor do I want to necessarily force them into every query.

In terms of an ORM library like Doctrine (or Propel), they tend to be huge, so that's a massive issue. Another thing we have to be aware of is the add-on community, ensuring that they can easily get the data they need out of the DB when they need it.

Any changes here wouldn't be before 2.0, as we're talking about some fundamental elements of XF's architecture.
 
Active Record has a terrible reputation for being unable to scale.
Please backup your statement, no point in making a rather bold statement...To my knowledge no forum software uses AR or has even tried it, so theres nothing to look at there. No point going with what everyone else says, I'm sure you've heard Ruby on Rails can't scale, well Twitter could handle 1 Billion+ queries per day using RoR. More than anything its down to architecture rather the AR.

@Mike 1:1 qureies don't have to be separate queries with AR, nor do you have to force them, have you heard of the concept behind "scopes"?

More than anything, in my opinion; it would make it easier for the add-on community.

Did you guys look at the Yii framwork? It claims to be faster than Zend and others, though thats not the reason I use it, its mainly down to how similar it is to RoR.
 
Please backup your statement, no point in making a rather bold statement...

And with Kier being unknowledgable in these areas, who could understand him being so bold in his statements o_O

To my knowledge no forum software uses AR or has even tried it, so theres nothing to look at there.

Ever thought there may be a reason for this?

No point going with what everyone else says, I'm sure you've heard Ruby on Rails can't scale, well Twitter could handle 1 Billion+ queries per day using RoR. More than anything its down to architecture rather the AR.
Twitter is hardly a good example, as the program is relativly simple. Successful yes, but its still relativly simple software.

@Mike 1:1 qureies don't have to be separate queries with AR, nor do you have to force them, have you heard of the concept behind "scopes"?

More than anything, in my opinion; it would make it easier for the add-on community.

Did you guys look at the Yii framwork? It claims to be faster than Zend and others, though thats not the reason I use it, its mainly down to how similar it is to RoR.

I wouldnt believe for one second that Kier and Mike have not looked into what they are doing before they have done it. However while I applaud you for trying, you are challenging 2 of the most experience people in forum software on the net in the architecture of forum software. Kier and Mike have been working on leading forum software using php for the past 10 years.

What I am trying to say is you seem to be making quite an assumption that Kier and Mike have not looked into any of these methods.
 
Please backup your statement, no point in making a rather bold statement...To my knowledge no forum software uses AR or has even tried it, so theres nothing to look at there. No point going with what everyone else says, I'm sure you've heard Ruby on Rails can't scale, well Twitter could handle 1 Billion+ queries per day using RoR. More than anything its down to architecture rather the AR.

Yes, and Twitter isn't known for having a lot of downtime/connectivity issues. :rolleyes: Not a good example of something that can scale easily.
 
I would say that "appealing to authority" isn't really a valid argument. I'm not the end-all, be-all authority on everything web development and neither is Kier.

Kier's reference is to the common "N+1" queries problem with AR, though that can be worked around. He simply stated it's reputation, and it has been a very common knock against RoR.

Though I didn't touch on this before per se, I'm not sure what repeated code is being referred to directly. We actually implement scope-like elements via our approach to setting conditions and fetch options. (Look at something like getThreads or getUsers.) Obviously this could be expanded/automated to some degree, if that's what you were referring to.

We do actually have various ideas that we want to explore, but they'd be a way off.
 
You guys have plenty to learn! No architecture/language guarantees scaleability. You have to pick the right tools for the task at hand! even then you might have to make changes. AR is simply one tool, which helps development.

@Marc Reason behind no one using it, I'm sure if someone had tried it and it failed, we would know about it.

Yes the Twitter concept is simple but the architecture is NOT. So I don't know what your getting at there? You really think its simple? wow!

I want @Kier to backup his statement for sure. You think hes some kind of God? lol I'm certainly not! He has plenty of experience with vBulletin so knows what works and have stuck to it while utilising the Zend Framework. I'm of the opinion that they borrowed the data-writer concept from vBulletin, even though it might be implemented differently.

@Onimua Twitter is an excellent example, not sure why you think the ability to handle 1 billion+ queries per day isn't good enough! There are plenty of high traffic sites on the internet that use RoR, heard of Groupon? It uses RoR!

Every company has issues, even google! Do you think its down to Python if Google goes down? Its mainly down to architecture or some other unknown issues, maybe even hardware.
 
You guys have plenty to learn! No architecture/language guarantees scaleability. You have to pick the right tools for the task at hand! even then you might have to make changes. AR is simply one tool, which helps development.

I somehow get the feeling you don't think Mike or Kier picked the "right tools for the task" here.
 
I was referring to you guys, not Kier or Mike.

@Mike I'm referring to constantly writing SQL statements, its purely valid to write SQL queries even with AR but it reduces the amount of queries you write...I'd love to work on XF full-time and share my ideas but thats not the case here.

I'd don't agree you have scope like functionality! With scopes I could go $unread = $threads->unread()->last24Hours()->findAll();

Even if you guys had a query builder it would be much better. I know Zend has a query builder but not sure if I should use it considering you guys might move away from Zend.

Kier and Mike guys are hugely talented no doubt but every one has different ideas, some better, equal or even worse.
 
I'm more than willing to challenge their assumptions if no one else is. Assuming they let us know first, which I doubt they would considering its an internal decision when it comes to architecture.
 
TBH I think the query builder depends on POV. For simple queries I would agree, however for a lot I would much rather build my own queries. Im not nearly as competent with php as many/most of you lot, however sql is something I do know a lot about. If you gave me ease of development over control I would probably be on middle ground on this one. Forcing people to look properly at the sql they are writing IMO can be more advantagious at times. The query builder in IPB is one of the very things I didnt like.

I think I was a bit OTT earlier and for that I appologies, however bare in mind in saying assumptions, you are also assuming that their decisions are based on assumptions rather than research. And if that sentence made sense, I'll be impressed LOL.
 
My point exactly, if they had done research, where is it? Remember Kier said reputation which to me suggested exactly what I thought.

I had the same opinions as you when I first read about Active Record but that all changed when I actually used it and understood how beneficial it is.
 
In Rails 3 lots of ActiveRecord query interface API changes appeared to make it more friendly, scalable and to improve query optimization. Since then Rails is using ARel (Relational Algebra). Which allows us to chain conditions, sorters, limits and groups etc. one after the other. Also, it uses lazy loading mechanism, hence, on every step we just get a relation object which can be modified dynamically. And at the end when we iterate through the result or fetch attributes of the result, at that time actual optimized/joined query is build and fired to the underlying database.

Having said that, it gives us many advantages in terms of lesser lines of codes to write with the help of features like associations, dynamic finders, scoping and above all, database agnosticism. Same application runs on MySQL, PostgreSQL, Oracle and why not SQLite? without any changes (except in the config file).

On crucial places when one feels that they can manually optimize certain queries better than ARel, they always have option to pass query string (sometimes on the cost of database agnosticism).

I would highly encourage you guys to check out Active Record Query Interface chapter from RailsGuides, at least chapters sub-headings from sidebar.

Rails had some scalability issues in the past but that was Rails 1 era. And now there is third generation of Rails, but people still have those thoughts in mind. It is similar to say that xF is missing some really important and must have features after two years from now. There are several high traffic and complex web applications loaded with social network graph relationship out there on the web, proving that there is no issue of scaling any more. See an old listing of some applications using RoR.
 
I'm sorry Sniper and ibnesayeed, but I'm am thoroughly confused. I see you guys talking about Ruby on Rails... Correct me if I'm wrong, but XenForo isn't written in Ruby on Rails... So how does any type of "ActiveRecord" improvements on their end make it any better for us. Its an invalid argument when you are talking about implementing it into a PHP based software. No matter HOW you try to spin it.
 
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.
 
I'm sorry Sniper and ibnesayeed, but I'm am thoroughly confused. I see you guys talking about Ruby on Rails... Correct me if I'm wrong, but XenForo isn't written in Ruby on Rails... So how does any type of "ActiveRecord" improvements on their end make it any better for us. Its an invalid argument when you are talking about implementing it into a PHP based software. No matter HOW you try to spin it.

Rails is just for a reference. Because, RoR relies on ActiveRecord heavily. ActiveRecord is just a concept and there are AR libraries available in various languages. Relational Algebra based optimization is also not limited to Rails only. Hope, you got an idea, why my last post used RoR references a lot.
 
Top Bottom