Search

For me, I've always found the existence of the ASDC extension odd. If the core isn't good (in terms of performance or security) enough: fix it. If there is a big difference in memory use between the core and the asdc, every extension (or installation) could benefit from it, not just the few that happen to know about the extension and why it should be used.

If I understand your point correctly standard DS'es could also benefit from this, correct? However, for them to use the ASDC would mean they'd have to check if the extension is installed, and then have a pile of duplicate code for the two situations (core or asdc).

So, please, if this extension is really necessary, please merge it with the core.

So, please, if this extension is really necessary, please merge it with the core.

Agreed! Apologies if I have spread misinformation about this extension. However I saw it as a drop-in replacement for Symphony's own MySQL class. I know several people who assumed it was a replacement for things like SymQL, which it absolutely is not. There's relatively little Symphony-specific code in the extension (beyond integration), so if it is indeed more performant, then it should be worked into the core.

if it is indeed more performant, then it should be worked into the core

Thumbs up.

if it is indeed more performant, then it should be worked into the core

Anyone up for a benchmark? I'd be willing to set one up after wednesday to see how big the differences really are.

Talk to Brendan about benchmarking (I assume you mean profiling?) he has been doing some work on that recently, and has some code in a branch.

Definitely a thumbs up from me too, this looks like it could be a start for sorting out our possible Active Record style approach?

I assume you mean profiling?

Nope, I mean benchmarking. We are already looking at a specific piece of code, so there is not really a need to profile. The reason for me to benchmark would be to see if there are any downsides to this. It might be very good for big datasets, but a burden for small ones, we don't know before we test both solutions.

And since we are discussing merging this into the core we better be sure it really is an improvement.

I'll shoot Brendan an email about it.

this looks like it could be a start for sorting out our possible Active Record style approach

No, that was my point! This is simply another way of creating the MySQL database connection, notthe way not the way Symphony stores data or creates objects, relationships or entries. It's primarily an optimised way of reading large data sets (rows from MySQL queries), and Symphony could/should quite easily be refactored (i.e. no API changes, pure internal optimisation) to use this instead. It doesn't have any bearing on ORM patterns etc.

If the core isn't good (in terms of performance or security) enough: fix it.

Security isn't an issue here as the core code is fine. It's more about dealing with large datasets. To be honest I have not actually properly bench-marked the code however some empirical testing Allen and I did a couple of years back suggest ASDC scales well, handling huge data sets much better than the core symphony code does, hence why it was used for this forum.

So, please, if this extension is really necessary, please merge it with the core.

I had a phone conversation with Allen on this topic, and we came up with what we think is a good solution. We both very much would like to see the ASDC code integrated into Symphony's core, however ASDC uses a totally different interface and thus would instantly break every extensions, data-source etc ever created. Instead, what propose is integrate ASDC into the core as the new DB library, and then re-implement the current MySQL class interface to use ASDC internally, but mark it as legacy code. Symphony won't know any different. This will means a number of things:

  1. Up front it will be reasonably trivial to get ASDC code into the core for a point release (2.3.2 perhaps)
  2. We can maintain backwards compatibility with all existing extensions, datasources and so forth.
  3. Developers will be able to tap into the ASDC code directly rather than having to install a separate extension.
  4. Symphony's core code can slowly be migrated to using the more efficient ASDC code

I have created a new fork and will work on this as I get time.

It might be very good for big datasets, but a burden for small ones, we don't know before we test both solutions.

You're right in that we don't know, however I believe that at worst there will be a negligible amount of additional overhead because we create iterator objects for result sets. That said, the code for operating on these result sets is simplified, so we could quickly gain back anything we lose. I'll look at getting some real numbers for you guys.

Security isn't an issue here as the core code is fine.

Sorry for being unclear. I meant that these improvements (security and performance) are things every installation should benefit from, and should thus be merged into the core, rather than being released as an extension.

I'll look at getting some real numbers for you guys.

That'd be great!

Something else, though. How MySQL specific are the methods the asdc uses? Is it possible to setup something like this using PDO?

The extension is one file: class.asdc.php. The methods themselves look fairly abstract, as if designed to be used with a RDBMS other than MySQL. But the code is pretty specific to MySQL.

Line 35 gives me the impression that the ASDC class was written with the possibility of extending it to other drivers.

The reason for me to ask is because the function used is deprecated in php..

However, without looking into it, I don't know if this way of getting results from the DB is possible with PDO (or mysqli, for that matter)

I think this is the chance to remove all the old "mysql" functions and also to switch to PDO!

Just my 2 cents.

Something else, though. How MySQL specific are the methods the asdc uses?

Currently it is MySQL specific, however, as bauhouse noticed, the ultimate goal was to allow drop-in of different drivers.

Is it possible to setup something like this using PDO?

Indeed this is something Allen and I spoke about and the plan is to re-examine the ASDC code at the same time I am integrating it. Symphony's core code doesn't use much vendor specific SQL, so fingers crossed it should be moderately easy to implement.

I think this is the chance to remove all the old "mysql" functions and also to switch to PDO!

I agree, but it will be an incremental process to preserve compatibility and may not be fully realised until 2.4 and beyond. We'll see how we go. :)

Thanks Alistair, this is really exciting! Symphony just gets better and better:)

Jens implemented a PoC for PDO yesterday during our Symphony chat, I believe he will look at updating the ASDC core integration code as well once it is available :)

Wrote a comment on GitHub about it to provide some details.

@jensscherbl it would appear we have the same goal and a similar approach to solving the problem. I would be more than happy to collaborate with you on this. :)

I would be more than happy to collaborate with you on this. :)

Awesome, just let me know how we should proceed.

Shoot me an email if you like (hi@alistairkearney.com) and we'll go from there.

Create an account or sign in to comment.

Symphony • Open Source XSLT CMS

Server Requirements

  • PHP 5.3-5.6 or 7.0-7.3
  • PHP's LibXML module, with the XSLT extension enabled (--with-xsl)
  • MySQL 5.5 or above
  • An Apache or Litespeed webserver
  • Apache's mod_rewrite module or equivalent

Compatible Hosts

Sign in

Login details