Lets kill some code... because the current code is madness.
If i'm correct a D8 install will start with a D6 base and run every update on it?

We should remove everything linked to D6 and D7 and start with a fresh schema.
I don't think my patch is ok as it leaves the old 6 schema, but it's a start for discussion

Comments

dawehner’s picture

StatusFileSize
new15.94 KB

One reason for having all this stuff in d7 was to have an easy way to port patches, but as the code is pretty stable this doesn't matter anymore.

Here is a patch with the adapted base schema.

aspilicious’s picture

can we adjust the doc header too than and why is it called schema_6000

aspilicious’s picture

Status: Active » Needs review
StatusFileSize
new17.09 KB

I think this should do it

aspilicious’s picture

StatusFileSize
new17.09 KB

tiny cleanup

tim.plunkett’s picture

Status: Needs review » Needs work

I've always been massively confused by views_schema(). Can't we eliminate all of that and just start with a clean, normal function?

Especially if this is to go into core.

aspilicious’s picture

Status: Needs work » Needs review
StatusFileSize
new18.62 KB

More cleanups

aspilicious’s picture

We should check if these are still needed

    db_query('CREATE OR REPLACE FUNCTION first(anyelement, anyelement) RETURNS anyelement AS \'SELECT COALESCE($1, $2);\' LANGUAGE \'sql\';');
    db_query("DROP AGGREGATE IF EXISTS first(anyelement)");
    db_query("CREATE AGGREGATE first(sfunc = first, basetype = anyelement, stype = anyelement);");
aspilicious’s picture

StatusFileSize
new19.13 KB

Now its all nice and clean :)

dawehner’s picture

+++ b/views.installundefined
@@ -11,84 +11,13 @@ use Drupal\Core\Database\Database;
-  if (Database::getConnection()->databaseType() == 'pgsql') {
-    db_query('CREATE OR REPLACE FUNCTION first(anyelement, anyelement) RETURNS anyelement AS \'SELECT COALESCE($1, $2);\' LANGUAGE \'sql\';');
-    db_query("DROP AGGREGATE IF EXISTS first(anyelement)");
-    db_query("CREATE AGGREGATE first(sfunc = first, basetype = anyelement, stype = anyelement);");

Can you please explain why this is not needed anymore?

+++ b/views.installundefined
@@ -11,84 +11,13 @@ use Drupal\Core\Database\Database;
-  // Generate a sorted list of available schema update functions.
-  if ($get_current || empty($schemas)) {
-    $get_current = FALSE;
-    $functions = get_defined_functions();
-    foreach ($functions['user'] as $function) {
-      if (strpos($function, 'views_schema_') === 0) {
-        $version = substr($function, strlen('views_schema_'));
-        if (is_numeric($version)) {
-          $schemas[] = $version;
-        }
-      }

Why don't we want this nice schema update mechanism?

aspilicious’s picture

Both are approved by Merlin, we decided (me, tim and merlin) after some discussion to remove all the custom code. The update mechanism was nice but according to Merlin it didn't solve every problem.

And Merlin said the pgsql fixes were really old and not needed anymore.

dawehner’s picture

Status: Needs review » Reviewed & tested by the community

Good to know!

tim.plunkett’s picture

Assigned: Unassigned » tim.plunkett

Going to manually test this today.

tim.plunkett’s picture

Issue tags: +VDC

I keep losing this one.

tim.plunkett’s picture

Assigned: tim.plunkett » Unassigned
Status: Reviewed & tested by the community » Fixed

Automatically closed -- issue fixed for 2 weeks with no activity.

larowlan’s picture

Version: 8.x-3.x-dev » 7.x-3.x-dev
Issue summary: View changes
Status: Closed (fixed) » Patch (to be ported)

This function is chewing through memory in some tests in D7, specifically the call to get_defined_functions() is this a backport candidate?

larowlan’s picture

Status: Patch (to be ported) » Needs review
StatusFileSize
new881 bytes

This at least kills off the get_defined_functions() which prevents OOM locally for me at least.

jibran’s picture

Nice catch. It has definitely improved the memory utilization.

dawehner’s picture

so @jibran did you tested the patch? I don't see a RTBC on this issue yet. Please try it out, ...

jibran’s picture

Status: Needs review » Reviewed & tested by the community

For some client work when I added https://www.drupal.org/project/views_datasource the site started giving memory limit error. After applying this patch the error went away. So yeah I have tested it.

larowlan’s picture

Yep, tested it on a client site as @jibran eluded

colan’s picture

We've recently switched our testing from the old qa.drupal.org to DrupalCI. Because of a bug in the new system, #2623840: Views (D7) patches not being tested, older patches must be re-uploaded. On re-uploading the patch, please set the status to "Needs Review" so that the test bot will add it to its queue.

If all tests pass, change the Status back to "Reviewed & tested by the community". We'll most likely commit the patch immediately without having to go through another round of peer review.

We apologize for the trouble, and appreciate your patience.

jibran’s picture

StatusFileSize
new881 bytes

Re-uploading the patch.

damienmckenna’s picture

Status: Reviewed & tested by the community » Fixed
Parent issue: » #2855120: Plan for Views 7.x-3.16 release

Committed. Thanks.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.