Symphony.

Hi there, Are there any custom DS examples out there?

Or some reference on how to do the sql queries and get the data, then construct the XML?

thanks! j

SymQL. It can return results as Array, Entry objects or XML. See the Readme.

Thanks but,

"It has no performance gains over standard Symphony data sources"

I'm looking to write my own DS for performance reasons. I have the SQL, but I need a reference how to put together a DS

j

DS performance is a great topic. It makes me feel to want to browse the forum once again and I will do. Not that most of my DSs would be utterly slow - under contrary. But some have the very potential.

What saves me there is Cacheable Datasource. And because I mostly use one page architecture for all the content, besides a RSS, Sitemap XML, 404, 403 page or alike (which may sounds I believe horrible, but I'm willing to improve. I know I am a fireball, at least 1:1), also the one and only Conditionalizer.

Anyway DSs are what makes the difference. It would be nice to have the performance info under one hood.

I have heard of creating a custom JOINS of existing DS requests. I would love to see an example for that.

OK, besides that there are the standard and great DS filtering, paging, essential chaining feature and also not picking too many fields if possible. I still learn some bits to this.

Sorry if I hijacked your thread. Wasn't meant. I do behave again.

bump, any custom datasource examples out there?

• Is the XML built with standard SimpleXML?
• How do I use the &$param_pool=NULL ?
• How can I write to the param_pool to create datasources for chaining?

Any pitfalls to look out for, or tips in general?

Thanks, J

@joe_g Not really sure if this will help you in any way, but here is an example of a custom DS I wrote (although not for performance reasons). I am writing the ID's directly to the param pool for chaining. here is a pastie

If you want I also have an example where I return the XML, but that's a whole lot bigger and less readable. When going this route I would recommend returning just the ID with the custom DS and chaining another DS to get the actual information - the queries explode really fast and managing them is a pain in the arse. If this is not doable for performance reasons you might want to consider caching. Since the cacheable ds will take params in consideration this is very painless and easy.

Thanks! Helpful indeed.

Example of returning XML would be great. I'm aware it's a maintenance nightmare. My sql is currently 100 lines long.

But I have no choice, I have an install that isn't fast enough because of over-use of the subsection manager (great for usability for the admin, but performance suffers). I tried all kinds of caching and it's not really enough (due to frequent updates). So the only way I can see is to make a mega-join and return all data in one go. It's blistering fast, 10ms instead of 1500ms, but it's quite unreadable indeed.