This is now blocked on #2057401: Make the node entity database schema sensible see #62 - #104.

Summary

After #1953800: Make the database connection serializable Drupal 8-x.dev fails to install if SQLite chosen as database system. Fixing 2 code errors in core/lib/Drupal/Core/Database/Driver/sqlite/Connection.php moves the install forward but not all tasks get completed even though install thinks it is finished. The install 'Standard Module' task is not done. There seems to be other issues in the install process that may not be strictly related to SQLite.

#1986902: Menu Rebuilding to late causing RouteNotFoundException during install
#1987262: [Installation Error] Symfony: "The service definition 'request' does not exist."
#2001350: [meta] Drupal cannot be installed on PostgreSQL
#2010322: SQLite follow up to #1953800 'Make the database connection serializable'
#2008644: FilterPluginManager::__construct calls CacheDecorator with incorrect parameters (expires)

Remaining tasks

With the commits of #2008644: FilterPluginManager::__construct calls CacheDecorator with incorrect parameters (expires) and #2010322: SQLite follow up to #1953800 'Make the database connection serializable' the problem has moved on and the install almost finishes. The remaining error seems to have been introduced by #1498674: Refactor node properties to multilingual. It created 2 new tables, 'node_field_data' and 'node_field_revision', that have both a 'type' => 'serial' column and a composite key. It causes an error 'table {name} has more than one primary key' error when install tries to create the tables and install finishes with errors. If the 'serial' column is changed to type 'int' the install finishes successfully. But then when any attempt is made to create content a 'Integrity constraint violation: 19 {table name} may not be NULL: INSERT INTO {table name}'. The exact error conditions may exist for SQLite only but there may be related problems in Postgres and Mysql support.

Problem Resolution

This issue has become a meta issue of sorts after a number of problems were discovered and resolved before that actual problem was diagnosed and a solution discussed. If you are unable to install D8 on the SQLite database you should track #2057401: Make the node entity database schema sensible. Once a fix is committed there this issue will be closed.

Original Report

Full error msg text:

Failed to connect to your database server. The server reports the following message: The service definition "request" does not exist.. 

I installed latest 8-x.dev, dated 5/19, on OS X 8.3 on macbook. In install process, after choosing SQLite as database, I get above message after clicking "Save and Continue". This is my normal process for building a 8-x install. Done it a hundred times. All permissions appear OK, no error messages in apache error log.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

dcrocks’s picture

On another system running OS X 10.6.8 I get the same failure. I also had an older 8-x tar dated 5/17. It fails the same way.

dcrocks’s picture

Dug around and found a 8-x.dev dated 5/05. Installs with no problem. Can narrow it down no further than the problem started after 5/05.

amateescu’s picture

dcrocks’s picture

Component: install system » sqlite database
Status: Closed (duplicate) » Active

I am not sure these are 'strictly' related, as I explained over there. The only thing I can verify so far is that the exception is caught during install on the 1st attempted connection in lib/drupal/core/database/driver/sqlite/install/Tasks.php. The only fix committed after 5/5 that affects the sqlite connection code(lib/drupal/core/database/driver/sqlite/Connection.php) was #1953800: Make the database connection serializable, which occured on 5/14.

Blooniverse’s picture

... what @amateescu#3 seems to mean is that your issue is primarily linked to a Container / Service Container deficiency. See links of comment#21 #1987262-21: [Installation Error] Symfony: "The service definition 'request' does not exist." for more details about this topic. Is Symfony new territory for you too?

However, your bug report is listed now in the summary of the mentioned issue, @dcrocks.

dcrocks’s picture

Status: Active » Closed (duplicate)

I agree it is the same problem. The call "Database::getConnection" directly results in the error. But I am stuck now and pretty ignorant about Symfony. If I find anything I will post there.

Blooniverse’s picture

... start with the two links given above. I have to work myself into Symfony too, step by step. And keep in mind: the title of #1974570: The service container is used before it's set in the drupal error handler seems to express quite distinctively in brief what the whole thing is about. The issue is, actually, not really that complex, is it!?!

dcrocks’s picture

Status: Closed (duplicate) » Active

I am going to open this back up as this problem doesn't seem related to #1987262: [Installation Error] Symfony: "The service definition 'request' does not exist.". I did apply the patch in #43 of that issue and finally getting an error msg to start from. The error shows up at the time I click 'save and continue' after having selected SQLite as my database type. The msg is

[Wed May 22 07:50:08 2013] [error] [client 127.0.0.1] PHP Fatal error: Call to a member function get() on a non-object in /Users/rocks/Sites/dru80522/core/lib/Drupal.php on line 147, referer: http://localhost/~rocks/dru80522/core/install.php?

Blooniverse’s picture

... well done, @dcrocks! If I were you I'd update the issue summary according to the guidelines on http://drupal.org/issue-summaries !

catch’s picture

Status: Active » Postponed (maintainer needs more info)

#8 is the same issue - the container isn't available when that method is called.

This is where it's failing:

 public static function request() {
    return static::$container->get('request');
  }

There may be another underlying bug here, but at least until #1987262: [Installation Error] Symfony: "The service definition 'request' does not exist." is fixed I don't think it's going to be possible to get to it.

dcrocks’s picture

I don't have a permissions problem, and, for me, the fix in #1987262: [Installation Error] Symfony: "The service definition 'request' does not exist." turns an exception into a fatal error. Getting that in doesn't get me much further down the road and perhaps it will be even harder to debug. At this point I know 2 things:
A call to Database::getConnection(); in lib/drupal/core/database/driver/sqlite/install/Tasks.php ends in the generation of the message block.
A call to to a function getDefinition in ContainerBuilder.php located in /core/vendor/symfony/dependency-injection/Symfony/Component/DependencyInjection/ generates the inner error msg: The service definition "request" does not exist.
I need to figure out the in between.

Blooniverse’s picture

... don't worry. Step by step we'll get closer! Under time pressure?

falcon03’s picture

Status: Postponed (maintainer needs more info) » Active

Definitely disappointed to see this happen.
I can confirm this (critical) issue; Drupal installs correctly using Mysql.

dcrocks’s picture

This started sometime after May 5th. That is the latest working copy of 8-x.dev I have. I didn't see the error until I tried a copy of 8-x.dev dated May 17th. There was a patch that affected database code on May 14th (#1953800: Make the database connection serializable). But I can't see anything in that mod that could do this. Maybe someone else can. If not that, then there are a lot of other commits since the 5th. If it is an ill-timed call to function request() in Drupal.php, I don't know where it is coming from.

dcrocks’s picture

Did a git clone of D8 today and reversed patch #1953800: Make the database connection serializable and got further. Clearly there must be a related patch but got past database select form and into 'init' stage. Process seemed to hang up twice with no errors in apache log but reloading page got it to finish. However drupal started as if I had selected minimal instead of standard. Didn't examine database created yet. I think it has something to do with form processing. Sqlite always reloads the form when selected. Be interesting if someone could try mysql but also click the 'advanced' form button.

dcrocks’s picture

I dumped $e just before the exception was processed and saw this:

Declaration of Drupal\Core\Database\Driver\sqlite\Connection::prepare() should be compatible with that of Drupal\Core\Database\Connection::prepare
amateescu’s picture

Status: Active » Needs review
FileSize
742 bytes

Hm.. could it be this easy. Can you please try this patch?

dcrocks’s picture

Definite progress but now fails in another place. The database file is created and then:

tring(14) "Strict warning" ["!message"]=> string(114) "Non-static method Drupal\Core\Database\Driver\sqlite\Connection::sqlFunctionRand() should not be called statically" ["%function"]=> string(53) "Drupal\Core\Database\Driver\sqlite\Connection::open()" ["%file"]=> string(86) "/Users/rocks/Sites/dru80526/core/lib/Drupal/Core/Database/Driver/sqlite/Connection.php" ["%line"]=> int(130) ["severity_level"]=> int(7) } [3]=> int(7) } } [4]=> array(4) { ["file"]=> string(52) "/Users/rocks/Sites/dru80526/core/includes/errors.inc" ["line"]=> int(77) ["function"]=> string(17) "_drupal_log_error" ["args"]=> array(2) { [0]=> array(7) { ["%type"]=> string(14) "Strict warning" ["!message"]=> string(114) "Non-static method Drupal\Core\Database\Driver\sqlite\Connection::sqlFunctionRand() should not be called statically" ["%function"]=> string(53) "Drupal\Core\Database\Driver\sqlite\Connection::open()" ["%file"]=> string(86) "/Users/rocks/Sites/dru80526/core/lib/Drupal/Core/Database/Driver/sqlite/Connection.php" ["%line"]=> int(130) ["severity_level"]=> int(7) ["backtrace"]=> array(18) { [0]=> array(7) { ["file"]=> string(86) "/Users/rocks/Sites/dru80526/core/lib/Drupal/Core/Database/Driver/sqlite/Connection.php" ["line"]=> int(130) ["function"]=> string(20) "sqliteCreateFunction" ["class"]=> string(3) "PDO" ["object"]=> object(PDO)#52 (0) { } ["type"]=> string(2) "->" ["args"]=> array(2) { [0]=> &string(4) "rand" [1]=> &array(2) { [0]=> string(45) "Drupal\Core\Database\Driver\sqlite\Connection" [1]=> string(15) "sqlFunctionRand" } } } [1]=> array(6) { ["file"]=> string(70) "/Users/rocks/Sites/dru80526/core/lib/Drupal/Core/Database/Database.php" ["line"]=> int(385) ["function"]=> string(4) "open" ["class"]=> string(45) "Drupal\Core\Database\Driver\sqlite\Connection" ["type"]=> string(2) "::" ["args"]=> array(1) { [0]=> &array(5) { ["database"]=> string(30) "sites/default/files/.ht.sqlite" ["namespace"]=> string(34) "Drupal\Core\Database\Driver\sqlite" ["driver"]=> string(6) "sqlite" ["prefix"]=> array(1) { ["default"]=> string(0) "" } 
dcrocks’s picture

Put in fix from #17 plus changed call in sqlite/Connection.php

public function sqlFunctionRand($seed = NULL) {
to
public static function sqlFunctionRand($seed = NULL) {

No error msgs but database install seems to hang up. I have to reload the page multiple times before everything is loaded. I also see 2 messages in the log file

Symfony\Component\Routing\Exception\RouteNotFoundException: Route "field_ui.display_overview.node.search_index" does not exist. in Drupal\Core\Routing\RouteProvider->getRouteByName() (line 146 of /Users/rocks/Sites/dru80526/core/lib/Drupal/Core/Routing/RouteProvider.php).
and
Notice: Undefined variable: finished in _batch_process() (line 305 of /Users/rocks/Sites/dru80526/core/includes/batch.inc).

The system also comes up with stark instead of bartik, as if not all initialization got done. It really looks as if I had selected 'minimal' instead of 'standard' profile.

dcrocks’s picture

I checked and I got the "Symfony\Component\Routing\Exception\RouteNotFoundException" 3 times in the last good install I have of 8-x(May 2nd). The same in an install from 4/19.
Looking some more at the new install, 'standard' module is not being installed. It appears the install is hanging after the 'init' stage and after the 'tour' module is enabled, right before 'standard' module is supposed to be installed. That is also where the exception is being reported.

dcrocks’s picture

FileSize
45.19 KB
45.09 KB

It always takes 2 page reloads to finish install. The 2nd will be after the tour module or after the Views UI module. 2 images attached show where processing stops.

dcrocks’s picture

Updated summary

dcrocks’s picture

Issue summary: View changes

Updated summary

dcrocks’s picture

I tried the patch in #1986902: Menu Rebuilding to late causing RouteNotFoundException during install. It does get rid of "Symfony\Component\Routing\Exception\RouteNotFoundException". The other error still occurs so it seems it is related to why "standard profile' module is not loaded. I tried a minimal install. It still hangs up once after 'initializing' msg displayed but then completes without further problem and the 'minimal profile' module is installed.

dcrocks’s picture

At a loss to understand what is going on. Tried different computers and different browsers. No errors in my apache logs and only the 2 I mentioned in #19 in drupal log. The circumstances are sightly different but it always takes 2 page refreshes to get install to complete and when it does 'standard profile' module isn't installed. It would help if someone else could try an install with the current fixes to see if it is only me or not.

dcrocks’s picture

Here is a revised patch

eule’s picture

i saw the same like #21 on my first installation..but didn´t see any error´s

dcrocks’s picture

@eule: Do you mean yow saw the install hang and refreshed the page to complete but the install completed successfully with the standard profile?

dcrocks’s picture

Title: Install fail - Failed to connect to your database server. » Install with SQLite fail - Failed to connect to your database server.

Made title more specific

dcrocks’s picture

Broke down and installed on mysql (blea). Installed with no problem. Back to a sqlite specific problem.

eule’s picture

@dcrocks

Do you mean yow saw the install hang and refreshed the page to complete but the install completed successfully with the standard profile?

i mean yes. i saw install hangs and i refresh the page, after f5 he finalize installation on this session.

but have no sqllite

dcrocks’s picture

Issue summary: View changes

Add related

dcrocks’s picture

Still unable to pinpoint error. Trying several other related patches change behavior, usually for the better. But now consistently failing on 'query' errors because 'node_type' table never created. Exception thrown by code flagged in #2001350: [meta] Drupal cannot be installed on PostgreSQL

Pancho’s picture

Assigned: Unassigned » Pancho

The freezes aren't random at all, but go back to filter and node modules, and possibly more.
In any case I'm getting closer. Hopefully done by tonight.

Pancho’s picture

Yippee, I got it!
Using the patch in #25 the install batch still freezes on installing filter and node modules.
Running module_enable() unbatched for a minimal profile gave me the following errors - the one after the other was fixed:

SQLSTATE[HY000]: General error: 1 table "node_field_data" has more than one primary key: CREATE TABLE {node_field_data} ( nid INTEGER PRIMARY KEY AUTOINCREMENT CHECK (nid>= 0), vid INTEGER NOT NULL CHECK (vid>= 0), type VARCHAR(32) NOT NULL DEFAULT '', langcode VARCHAR(12) NOT NULL DEFAULT '', default_langcode INTEGER NOT NULL DEFAULT 1, title VARCHAR(255) NOT NULL DEFAULT '', uid INTEGER NOT NULL CHECK (uid>= 0) DEFAULT 0, status INTEGER NOT NULL DEFAULT 1, created INTEGER NOT NULL DEFAULT 0, changed INTEGER NOT NULL DEFAULT 0, comment INTEGER NOT NULL DEFAULT 0, promote INTEGER NOT NULL DEFAULT 0, sticky INTEGER NOT NULL DEFAULT 0, PRIMARY KEY (vid, langcode) ); ; Array ( )

SQLSTATE[HY000]: General error: 1 table "node_field_revision" has more than one primary key: CREATE TABLE {node_field_revision} ( nid INTEGER NOT NULL CHECK (nid>= 0), vid INTEGER PRIMARY KEY AUTOINCREMENT CHECK (vid>= 0), langcode VARCHAR(12) NOT NULL DEFAULT '', default_langcode INTEGER NOT NULL DEFAULT 1, log TEXT NULL DEFAULT NULL, revision_timestamp INTEGER NOT NULL DEFAULT 0, revision_uid INTEGER NOT NULL CHECK (revision_uid>= 0) DEFAULT 0, title VARCHAR(255) NOT NULL DEFAULT '', uid INTEGER NOT NULL CHECK (uid>= 0) DEFAULT 0, status INTEGER NOT NULL DEFAULT 1, created INTEGER NOT NULL DEFAULT 0, changed INTEGER NOT NULL DEFAULT 0, comment INTEGER NOT NULL DEFAULT 0, promote INTEGER NOT NULL DEFAULT 0, sticky INTEGER NOT NULL DEFAULT 0, PRIMARY KEY (nid, langcode) ); ; Array ( )

SQLSTATE[HY000]: General error: 25 bind or column index out of range: INSERT INTO {cache} (cid, serialized, created, expire, tags, checksum_invalidations, checksum_deletions, data) VALUES (?, ?, ?, ?, ?, ?, ?, ?); Array ( [0] => filter_plugins:en [1] => 1 [2] => 1370073388 [4] => [5] => 0 [6] => 0 [7] => a:6:{s:24:"filter_html_image_secure"; ...

The first ones were due to the fact that a 'serial' resp. AUTOINCREMENT field is automatically considered a primary key by SQLite - which actually makes sense - and that there obviously can't be two of them.
On the latter one do you see that value [3] is missing? This is due to a tiny little bug in FilterPluginManager that called cache()->set() with the wrong count of parameters. Unfortunately the error message wasn't too helpful, but we can be thankful that SQLite seems to throw up some bugs that MySQL silently swallows...

Patch will be following by tonight after I successfully tested everything with the different database backends.

dcrocks’s picture

Great news. I had seen the "more than one primary key" msg before in my many attempts, but on a different table. I just couldn't get consistent results. The fix in #25 needs to be redone as supplying the type hint is all that is necessary to remove the 'compatibility' error. With #25 and fix in #2008644: FilterPluginManager::__construct calls CacheDecorator with incorrect parameters (expires) I still can't install, as a number of tables just don't get installed. Looking forward to what you come up with.

Pancho’s picture

Assigned: Pancho » Unassigned
FileSize
3.12 KB

Installer runs fine again.
Only importing translations and updating config translations is (still) veeery slow on SQLite, but that's another issue.
Should really be ready for review now... :)

Pancho’s picture

D'Oh, so there was already a patch for the bug in FilterPluginManager...
So apart from amateescu and dcrocks, please don't forget mentioning mradcliffe in the commit message!

dcrocks’s picture

Suggest just change line

 public function prepare($query, $options = array()) {
    to
 public function prepare($query, array $options = array()) {

as the compatibility error was just about the type hint and this way the call looks the same everywhere.

dcrocks’s picture

Tried patch in #35 on most recent 8-x.dev with SQLite selected as the database. Install succeeds without error except still get "RouteNotFoundException" warning msgs. That is still waiting on #1986902: Menu Rebuilding to late causing RouteNotFoundException during install but doesn't seem critical. I was able to enable additional modules with no problem.

However, whenever I attempt add any content(I tried 'basic page', 'article', and 'forum entry' I get the same 2 errors each time.

Drupal\Core\Database\IntegrityConstraintViolationException: SQLSTATE[23000]: Integrity constraint violation: 19 node_field_revision.vid may not be NULL: INSERT INTO {node_field_revision} (nid, langcode, default_langcode, log, revision_timestamp, revision_uid, title, uid, status, created, changed, comment, promote, sticky) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?); Array ( [0] => 1 [1] => en [2] => 1 [3] => [4] => 1370107082 [5] => 1 [6] => Test Page [7] => 1 [8] => 1 [9] => 1370107082 [10] => 1370107082 [11] => 1 [12] => 0 [13] => 0 ) in Drupal\Core\Database\Connection->query() (line 568 of /Users/rocks/Sites/dru80531/core/lib/Drupal/Core/Database/Connection.php).

Drupal\Core\Entity\EntityStorageException: SQLSTATE[23000]: Integrity constraint violation: 19 node_field_revision.vid may not be NULL: INSERT INTO {node_field_revision} (nid, langcode, default_langcode, log, revision_timestamp, revision_uid, title, uid, status, created, changed, comment, promote, sticky) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?); Array ( [0] => 1 [1] => en [2] => 1 [3] => [4] => 1370107082 [5] => 1 [6] => Test Page [7] => 1 [8] => 1 [9] => 1370107082 [10] => 1370107082 [11] => 1 [12] => 0 [13] => 0 ) in Drupal\Core\Entity\DatabaseStorageControllerNG->save() (line 410 of /Users/rocks/Sites/dru80531/core/lib/Drupal/Core/Entity/DatabaseStorageControllerNG.php).

I have not tested a mysql installation to see if it also fails, but I think someone would have flagged an issue by now. I need to look at the history of the failing code to see where these errors might have been introduced, or, if the code hasn't been changed since May 5th(last working copy I have), then there must be something more fundamental.

Pancho’s picture

Status: Needs review » Needs work

Okay, so back to work. :(
Will take another look at it tonight.

dcrocks’s picture

RE: "more than one primary key". Drupal has code in its SQLite support to handle columns of type 'serial'. It automatically converts it to "INTEGER PRIMARY KEY AUTOINCREMENT". However 2 new tables, 'node_field_revision' and 'node_field_data', were added that have composite primary keys. But they left the designation of 'serial' on one of the keys. It is those 2 that have to be changed. In mysql "SERIAL is an alias for BIGINT UNSIGNED NOT NULL AUTO_INCREMENT UNIQUE", so we should change the field appropriately so we don't introduce problems for mysql.

Pancho’s picture

In mysql "SERIAL is an alias for BIGINT UNSIGNED NOT NULL AUTO_INCREMENT UNIQUE", so we should change the field appropriately so we don't introduce problems for mysql.

In SQLite, only primary keys can autoincrement, and whatever autoincrements is a primary key, see FAQ and Autoincrement.

So that is not possible in SQLite. I can't say "unfortunately" because I think it makes quite some sense. If we're having a unique column anyway, and even an autoincrementing one, there is just no point in having another primary key or - even less performant - a composite primary key. See #1498674: Refactor node properties to multilingual:

The main culprit here seems to be the composite primary key, in fact dropping it and setting just nid as primary key makes the monolingual query above as performant as in the current HEAD.

Besides performance, this simply can't be solved SQLite only. But even if it could, it shouldn't.

dcrocks’s picture

The only tables I found that had a key column type 'serial' and composite primary keys other than the ones you found were in 'entity_test.install', which implies that system tests would fail if they were run with SQLite instead of mysql. SQLite's driver schema.php has code to handle composite primary keys but it apparently doesn't work.

Pancho’s picture

I still believe that this is no bug with SQLite or our SQLite implementation at all. Our problem is not that SQLite wouldn't cope with a composite primary key.
It rather seems very crude what we're doing with these non-unique autoincrement columns in our new {node_field_data} and {node_field_revision} tables. It seems to be simply due to MySQL's tolerance that this is working at all. Wouldn't be sure about PostgreSQLbut will test that ASAP.

Pancho’s picture

We should break out and prepone #2008644: FilterPluginManager::__construct calls CacheDecorator with incorrect parameters (expires) because it:

  • applies to both postgreSQL and SQLite
  • is obvious and not debatable
  • and is a prerequisite to getting the other bugs fixed here.

Would be nice if you guys could give the latest patch a review over there.

Pancho’s picture

(continuing #43:)
D8 install on postgreSQL is broken as well, so we need to fix #2001350: [meta] Drupal cannot be installed on PostgreSQL first before we can correctly check whether postgreSQL correctly supports conditional autoincrementing if no value is given, which is finally happening here.

dcrocks’s picture

Have to get the code errors introduced by #1953800: Make the database connection serializable before I can test anything else. That stops SQLite at the database selection form. Am going to do that as separate issue as that isn't the only thing wrong.

dcrocks’s picture

Title: Install with SQLite fail - Failed to connect to your database server. » Cannot install Drupal 8 on SQLite

Revised title and added related

dcrocks’s picture

Issue summary: View changes

Added related.

dcrocks’s picture

Perhaps we should make the problems introduced by #1498674: Refactor node properties to multilingual a separate patch also. It looks like, in the end, this will be fixed by a multitude of other issue patches, not all related to SQLite.

jthorson’s picture

Status: Needs work » Needs review
dcrocks’s picture

Status: Needs review » Needs work

I think there is a problem with the assumptions made by SQLite's schema.php that didn't show up until #1498674: Refactor node properties to multilingual introduced tables with composite keys. When creating a table, the code assumes that if the table has a column identified with 'type' => 'serial' then that column is the only primary key and builds the appropriate sql to identify it as such. And if it also has a 'primary key' constraint then it will only have one element and by 'unset'ing the key in that element it removes any possible "table has more than one primary key" error. The sql definition for a column with 'type' => 'serial' will always be

"{name} INTEGER PRIMARY KEY AUTOINCREMENT CHECK ({name}>= 0)".

This eliminates the "trying to insert a NULL into a 'not null' column" error. And since no tables before #1498674: Refactor node properties to multilingual had composite keys the 'primary key' constraint would always be empty.

I would expect the correct response would be to modify SQLite's schema.php to support composite keys. Whether or not they are desirable, for performance or any other reason, I don't think you can assume they won't appear in the future. Since both mysql and postgres both recognize 'type' => 'serial' they probably don't have any issues with composite keys. This probably deserves some analysis though.

dcrocks’s picture

The patch in #35 is no longer correct given that the problem has been broken up into multiple issues. What is needed here is a new patch to add composite key support in SQLite's schema.php.

Pancho’s picture

Sorry again, but this is not about schema.php not supporting composite primary keys. We have more of them (see {users_data}) and they work fine.

When creating a table, the code assumes that if the table has a column identified with 'type' => 'serial' then that column is the only primary key and builds the appropriate sql to identify it as such.

Yes, and that is correct. I linked the relevant SQLite docs in #41.
In SQLite there is no way to create an AUTOINCREMENT other than declare a column INTEGER PRIMARY KEY.
And it is obvious that there can't be two Primary Keys, the AUTOINCREMENT column and a composite key.

[edit:]
One way would be changing the schema definition of the new {node_field_data} and {node_field_revision}, and in order to avoid such problems in the future, we should then disallow 'serial' for columns that aren't primary key by itself.
Then the value always has to be given by our code.

Another way would indeed be translating 'serial' to a regular INTEGER here, because it isn't a primary key, and adding a trigger to increment the value if none has been passed.

[edit 2:]
While the one would be a more generic solution, the other would be a MySQL optimization with SQLite workaround.
We should probably go both ways and profile them with all of InnoDB, MyISAM, PostgreSQL and SQLite.
But first of all we need to get Drupal working again on PostgreSQL and see how nextval() does the job there.

dcrocks’s picture

All the other tables that have a composite key also don't have any columns with 'type' => 'serial'. That seems the accepted but undocumented practice.

dcrocks’s picture

Issue summary: View changes

Added related

dcrocks’s picture

Issue summary: View changes

Update problem status

Gábor Hojtsy’s picture

The reason nodes need a compound key is they can store different property values now for the same nid per language. So the nid is not anymore a unique identifier for a specific node. When a new node is created, the nid should increase, but when additional information is stored for a node, an existing nid will be reused with a different langcode combination.

plach’s picture

Agreed with #54.

This is just a stupid copy/paste error of mine: we just need the composite key. In fact nid here will always be known so the correct type should be 'int' (unsigned, not null) and not 'serial', exactly as the field data/revision schema.

Sorry for getting in the way :(

amateescu’s picture

Status: Needs work » Needs review
FileSize
729 bytes

Here we go.

Gábor Hojtsy’s picture

Issue tags: +Needs upgrade path

Needs upgrade path.

amateescu’s picture

FileSize
1.27 KB

From.. what? We didn't have these tables in D7. Also changed these columns in _node_update_8016_schema().

Pancho’s picture

Status: Needs review » Needs work

Except for the upgrade path, that's what I had before in #35. Ignore the other stuf, which has already been committed in other issues.

Now turning the serials to regular ints makes the installer work again, but then when a new node is added, the value is not passed in and integrity constraint violations were thrown.

Therefore, in #52, my question was, whether we want to pass the values in or use a trigger as a workaround for SQLite. If the serial definition wasn't on purpose, the former seems to be the case.

Also the comments need to be fixed:

'description' => 'The primary identifier for a node.',
[...]
'description' => 'The primary identifier for this version.',

So resetting to needs work.

tstoeckler’s picture

Seems like we need NodeStorageController (or in fact DatabaseStorageControllerNG?) to initialize IDs with Connection::nextId()?!

plach’s picture

I think DatabaseStorageControllerNG should just use the nid obtained after creating the base table record to populate the data and revision table records.

Damien Tournoud’s picture

Title: Cannot install Drupal 8 on SQLite » Database storage for the node entity doesn't make any sense
Component: sqlite database » node.module

The database schema for node doesn't make any sense. I would recommend just reverting the translatable properties patch that introduced the mess in the first place.

On the issues:

  • (nid, langcode) seems to be the intended primary key of the {node} table, but:
    • The defined primary key is (nid) and changing that would break the assumption that serial columns are read-only and need to be the primary key of the table (assumption that holds true for SQLite, SQL Server and Oracle, and is basic database design anyway);
    • uuid is a unique key
  • The real primary key of node is really (nid), whether you want it or not. A node has a path of node/xxxx, and as a consequence its primary key need to be (nid).

As a consequence of the above, {node} need to keep its primary key of (nid) and the translatable properties stuff need to either be refactored into a database schema that actually makes sense or be reverted completely.

This is not a SQLite issue, the current schema prevents porting Drupal to SQLite, SQL Server and Oracle.

plach’s picture

It's too late for a proper answer, but I just want to say that

(nid, langcode) seems to be the intended primary key

is simply false: {node}.nid IS the intended PK. The data/revision tables are meant to work exactly as field ones and those are working on other DBMS than MySQL AFAIK.

I think this discussion is OT here, anyway.

Damien Tournoud’s picture

{node}.nid IS the intended PK. The data/revision tables are meant to work exactly as field ones and those are working on other DBMS than MySQL AFAIK.

They are radically different, because the (1) data table stores the reference to the current revision and (2) the revision table allocates the revision id. I think the intend is for the data/revision table to work like the previous node/node_revision table.

I think this discussion is OT here, anyway.

This discussion is exactly the topic. The current schema is not going to work on SQLite, SQL Server and Oracle, not because of limitations of those engines, but just because it is broken to the point of being meaningless.

Gábor Hojtsy’s picture

So in Drupal 8, I believe the idea is the only non-language dependent values of a node is the nid, the current rid and the type. The nid can theoretically be a primary key for those three things. Anything else beyond that is language dependent and cannot be identified/loaded with the nid only. Nid is not a unique identifier for those further things. Yes, a nid may be in the URL for the node (and language may not be), but the variant of the node displayed is decided based on language conditions for the page, and you don't get *the* node view or *the* node editing, you get a node view or a node editing for a language variant (with language maybe not even in the URL). BTW this concept is already present in Drupal 7, the only difference in Drupal 8 is this does not only apply to configurable fields, so nid is not only inadequate as a primary key for configurable fields, but now also for intrinsic properties.

Damien Tournoud’s picture

@Gábor Hojtsy: could you describe the intention between the different tables?

Specific questions:

  • What's the intention behind {node}.langcode? Is this the "default" language of the node? (whatever that can mean?) Why is the default '' instead of something more specific?
  • What's the difference between {node}.vid and {node_field_data}.vid? Is there a "current revision" per language or is the "current revision" valid for the whole node?
  • I see that *all* the properties are now per language (including technical stuff like created, updated, sticky etc. Are we certain that we are leveraging those properly everywhere in the code base, and do we have the critical issues open to fix when we are not? As we found at during the Drupal 7 cycle, implementing language branching / fallback in SQL is *really hard*. I hope this has been thought through.
  • {node_field_revision}.default_langcode is per-revision, but {node}.langcode is not. Are we doing the right thing on revert/deleting revision?

At the minimum, it seems like we are missing a {node_revision} table, that will allocate the vid, if it is not per language. If the vid is intended to be per language, we have other things to fix.

plach’s picture

Status: Needs work » Needs review
FileSize
2.3 KB

Damien, first of all let me remark that I didn't mean to dismiss your concerns in any way by saying #62 is OT, what I meant is that this specific issue is about being able to complete an installation on SQLite. I was proposing to introduce here just the minimum amount of changes needed to call this fixed. However I didn't realize we have a serious issue with vid allocation that MySQL is completely hiding (4AM, my bad).

Rolling back #1498674: Refactor node properties to multilingual is not something D8MI can afford at this point of D8 development, what we can do is fixing the current situation, which I believe is not impossibly hard, and address the rest of your concerns in dedicated issues. AAMOF I was going to start working on entity storage in the upcoming days, so we could have the chance to find a proper answer to all of them in the context of a more general issue. I'd be really really glad if you could help with your insights over there :)

Some short answers to #66:

What's the intention behind {node}.langcode?

I think the original idea was mimicking {node}.vid, i.e. the variant identifier, however since we introduced {node_field_data}.default_langcode, it might no longer make sense given that {node} is not going to be used for querying usually.

What's the difference between {node}.vid and {node_field_data}.vid? Is there a "current revision" per language or is the "current revision" valid for the whole node?

As Gabor was pointing above, we are not going to support revisioning by language, just providing different translations of a particular revision. I think {node_field_data}.vid was originally introduced to mimick field tables, but since now {node_field_revision} is being used as data table on entity loading, I guess we might not actually need it. However I'd wait to go through the entity storage stuff before dropping it, just in case...

I see that *all* the properties are now per language. [...] I hope this has been thought through.

The first thing to point out is that I don't think we should support language fallback while querying. Translation sets didn't provide an easy way to do it either: you could get all french or language-neutral published nodes, but not getting english nodes if french nodes were not available, not in an easy way however. The new schema combined with entity loading will allow us to support language fallback to some extent (see the Querying paragraph of the change notice), but I don't think we should support more than that. That said, I tried my best to wrap my mind around the various use cases while working on the various conversions and I didn't identify critical stuff, but given the amount of queries involved I cannot guarantee I didn't miss something :)

{node_field_revision}.default_langcode is per-revision, but {node}.langcode is not. Are we doing the right thing on revert/deleting revision?

Good point, not sure about this. Probably another clue that we might not actually need {node}.language. As above I'd defer dropping it after the entity storage conversion to be sure we are not missing something. AAMOF removing it will make mapping between records and entity objects a bit trickier.

At the minimum, it seems like we are missing a {node_revision} table, that will allocate the vid, if it is not per language.

What about quickly fixing vid allocation here and discussing a more advanced solution in the entity storage issue(s)? I think the current table layout might make sense as revisions are just data varations, hence a {node_revision} table would hold just the vid column, unless I'm missing something. I think a good strategy for now could be retrieving a vid through Connection::nextId() before writing a new revision record, patch attached (hopefully tests aren't making wrong assumptions on nid equalling vid).

Status: Needs review » Needs work

The last submitted patch, node-vid_null-1998366-67.patch, failed testing.

Damien Tournoud’s picture

Ok, so based on the answers above, we have the following issues:

  • {node}.langcode needs to be dropped, as it is just a denormalization,
  • We need a {node_revision} table to allocate the vid,
  • {node_field_data}.nid should be a int, not serial (already in the patch),
  • The primary key of {node_field_data} should be nid, langcode, not nid, vid, langcode
  • We can drop the {node_field_data}.nid index that is redundant,
  • {node_field_revision}.vid should be a int, not serial (already in the patch),
  • The primary key of {node_field_revision} should be vid, langcode, not nid, vid, langcode
  • We can drop the {node_field_revision}.nid and {node_field_revision}.vid index that become redundant.

I do not think it is a good design decision to make all the properties translatable. You can select which configurable fields can be translated or not. In most use-cases, uid, created, changed, comment, promoted and sticky are going to be the same for all languages (I am not saying that there are no use case for them to be translated, just that those are not the most common use-cases).

More specifically, changed should really not be translated, as it is a essentially a property of the revision and as a consequence should be the same for all language because we don't have revisions per language.

As I have been saying about a year ago, it would have been a way better and scalable design to make all of those configurable fields.

plach’s picture

We need a {node_revision} table to allocate the vid,

Just the vid? Are you ok with quickfixing this as proposed in #67?

I do not think it is a good design decision to make all the properties translatable.
[...]
As I have been saying about a year ago, it would have been a way better and scalable design to make all of those configurable fields.

I know you said this already one year ago, what you didn't AFAIK was providing a convincing argument that this would not cause a serious performance regression.

This is not to say that I wouldn't love to make everything a configurable field, I suggested to do exactly that when proposing the concept of translatable field years ago, but I was shot down almost immediately. We left this option open even in the change notice, but we need to be sure it's a viable way and nothing I saw so far, including the numbers in #1498674: Refactor node properties to multilingual, seems to suggest that :(

Damien Tournoud’s picture

We need a {node_revision} table to allocate the vid,

Just the vid? Are you ok with quickfixing this as proposed in #67?

No, I'm not ok with it. The quickfixing looks pretty horrid. As long as we rely on the database to allocate IDs, we should do it the proper way.

{node_revision} should hold the following columns in addition to the vid: log, revision_timestamp, author_uid (as those belong directly to the revision, not to the translation of the revision).

It's going to be less consensual, but I would like to see created and changed moved there too.

I know you said this already one year ago, what you didn't AFAIK was providing a convincing argument that this would not cause a serious performance regression.

I do not remember any discussion about performance. I don't see how using the field architecture can affect performance. What can affect performance is the database schema, but it is *also* the case with the current schema. Doing simple things like storing nodes by decreasing created date is going to be dog slow with the new schema as compared to Drupal 7, but would not be slower using a proper field schema.

plach’s picture

Doing simple things like storing nodes by decreasing created date is going to be dog slow with the new schema as compared to Drupal 7, but would not be slower using a proper field schema.

Yes, but selecting 10 published nodes promoted to the front page sorted by title would be way slower with fully normalized field tables, I am afraid.

plach’s picture

Anyway I want to make officially clear that I have no interest in the particular table layout we choose as long as it fully supports multlingual and it doesn't completely cripple performance. What I really care for is having a proper API encapsulating it, so that everyone can implement its own custom table layout, fitting their needs. The node schema is the most complex we need to address, at least in core. It was a good exeperiment to fully understand the problem space, I (at least) definitely needed it. I really wish we could work together during the last year: after your Denver session I was completely hopeful we would find a way to accomodate things in a way everyone would be ok with. Now it's late.

I am going to fix this stuff as fast as I can and then turn to the Entity Storage API issue(s), as I would like to do since one year ago.

fago’s picture

{node}.langcode needs to be dropped, as it is just a denormalization,

I don't think so - the denormalization is more in the field_data table - not? A node has just one (original) langcode, which is repeated in the default_langcode column. Howsoever, sure if the default_langcode flag is enough to have the original langcode be properly querable also, I guess we could live with this one only.

Suggestions of #69 sound very reasonable to me (without having looked into the details)!

I think {node_field_data}.vid was originally introduced to mimick field tables,

I think the thought behind that was denormalization, so you can go with a language specific node_field_data table instead of node. However, yeah - that should be clearly noted/documented there then.

So yep, we've quite something to clean-up here.

plach’s picture

log, revision_timestamp, author_uid (as those belong directly to the revision, not to the translation of the revision).

Not sure about this. There are use case to track these by language: a translator updating the translation of a revision might want to translate also the log, and we may want to record who's actually updating that revision. This is something contrib may expand on even if the core UI does not provide a way to enter those values per-language.

Damien Tournoud’s picture

{node}.langcode needs to be dropped, as it is just a denormalization,

I don't think so - the denormalization is more in the field_data table - not? A node has just one (original) langcode, which is repeated in the default_langcode column. Howsoever, sure if the default_langcode flag is enough to have the original langcode be properly querable also, I guess we could live with this one only.

{node}.langcode and {field_data}.default_langcode are clearly redundant, but one is common to all revisions of the node, the other is per-revision. That clearly is not going to fly.

So we have two options:

  1. We add {node_revision}.langcode as part of the new {node_revision} table, and we make sure that we properly update the flag, or
  2. We drop the {node}.langcode and we only store the information in {field_data}.default_langcode

Presented like that, I'm actually leaning toward (1).

Not sure about this. There are use case to track these by language: a translator updating the translation of a revision might want to translate also the log, and we may want to record who's actually updating that revision. This is something contrib may expand on even if the core UI does not provide a way to enter those values per-language.

As far as I understand, right now log, revision_timestamp, author_uid are *per revision*, not *per revision language*. It makes little sense to translate them, especially since you probably want to create a revision when translating to begin with. Every use case that I have seen with strong translation workflow all had strong revision requirements.

plach’s picture

As far as I understand, right now log, revision_timestamp, author_uid are *per revision*, not *per revision language*.

This was the only part not covered by the spec so I improvised a bit here: the end goal was being able to enter all the above values per-language, through a contrib module since nothing in core allows to do that. I could be fine with every new translation being a new revision when needing to have those value per-language, but I think we definitely need more feedback about this. Gabor?

fago’s picture

So we have two options:
We add {node_revision}.langcode as part of the new {node_revision} table, and we make sure that we properly update the flag, or
We drop the {node}.langcode and we only store the information in {field_data}.default_langcode
Presented like that, I'm actually leaning toward (1).

I'm not sure we made the "langcode" revisionable on purpose, but I'm ok with doing so.

Afaik the reasoning behind having default_langcode in node_field_data was to ease querying, i.e. you save a join and comparison when querying for an entity in default language. Do you agree that this optimization makes sense? If so, we should keep it I guess.

At the minimum, it seems like we are missing a {node_revision} table, that will allocate the vid, if it is not per language. If the vid is intended to be per language, we have other things to fix.

Yep, we missed the vid-allocation issue.

As far as I understand, right now log, revision_timestamp, author_uid are *per revision*, not *per revision language*.

Afaik, the idea was that those are language-aware as well. So you can have that metadata for each translation of the revision.

It makes little sense to translate them, especially since you probably want to create a revision when translating to begin with. Every use case that I have seen with strong translation workflow all had strong revision requirements.

Even when you create a new revision when you start translating, the timestamp would still apply to the revision. E.g., it would be quite hard to answer the question of when was translation X last updated as the info would be hidden somewhere in the revision history, whereas with the current model it's part of the current revision.
With the current model, you can make a change + translate this change in the same revision. Seems reasonable to me?

{node}.langcode needs to be dropped, as it is just a denormalization,
We need a {node_revision} table to allocate the vid,
{node_field_data}.nid should be a int, not serial (already in the patch),
The primary key of {node_field_data} should be nid, langcode, not nid, vid, langcode
We can drop the {node_field_data}.nid index that is redundant,
{node_field_revision}.vid should be a int, not serial (already in the patch),
The primary key of {node_field_revision} should be vid, langcode, not nid, vid, langcode
We can drop the {node_field_revision}.nid and {node_field_revision}.vid index that become redundant.

Looking through them, I agree with all of that.

Also, from looking at the storage controller code it looks like node_field_revision gets used during a regular entity load, while when mimicking field API logic it should be used only for loading non-default revisions?

Gábor Hojtsy’s picture

re #77: The revisions system for nodes works so that if you update/save nodes on the UI, you'll update/add one revision at a time in one language. The API allows for saving multiple language changes in one revision, even if the UI does not. I don't think we should spend *any* time on trying to support translatable revisions messages, this sounds like a very bad idea to focus any of our energies at the moment.

plach’s picture

Actually supporting translatable revision messages (only at storage-level) will require less changes than moving all the revision columns back onto a node_revision table. Anyway I don't have a strong preference: just let me know which column the resurrected {node_revision} table needs to have and I'll write a patch :)

Gábor Hojtsy’s picture

All I care is we work on problems that matter most :)

catch’s picture

While it's more changes I think it'd be a lot less confusing having the log message on the revisions table itself. I remember being confused by this when it was first added. However that could be a normal/major follow-up to this issue.

plach’s picture

@catch and @DamZ agreeing is enough for me, but I'll wait a bit more to give people a last chance to speak.

dcrocks’s picture

With the other issues that have been committed and the patch in #67 I can install D8 on SQLite and add simple content. I am not testing multilingual capabilities and the issues I am trying to contribute to are pretty far from this one. I would like to see this one finished with a strong fix, but not to go on forever. I am looking forward to a new patch soon.

Damien Tournoud’s picture

Title: Database storage for the node entity doesn't make any sense » Improve the database schema of the node entity storage

I updated the issue summary based on what I understand of the last discussions. Also toning down the title for good measure.

Damien Tournoud’s picture

Issue summary: View changes

Simplify summary.

Damien Tournoud’s picture

Issue summary: View changes

Update the plan.

plach’s picture

Assigned: Unassigned » plach

I'm going to start working on this soon.

effulgentsia’s picture

@catch and @DamZ agreeing is enough for me, but I'll wait a bit more to give people a last chance to speak.

Sorry I didn't comment sooner, but I just read the issue summary (not any issue comments except the last few), and I can't think of any objections.

plach’s picture

Issue tags: +D8MI, +sprint, +language-content

Tagging for the rocketship

andypost’s picture

catch’s picture

Issue tags: +D8 upgrade path

Tagging with upgrade path - don't want to have to do a beta-beta upgrade path for this one.

plach’s picture

Assigned: plach » Unassigned

Sorry, I wasn't able to work on this yet, I still have one critical task to complete. If someone wishes to start with this meanwhile, feel free.

dcrocks’s picture

Did want to note that at least the error is less obfuscated on the latest dev D8-x. Without patch in #67 install fails while creating the database with:

An AJAX HTTP error occurred.
HTTP Result Code: 200
Debugging information follows. ...
.....
....
SQLSTATE[HY000]: General error: 1 table "node_field_data" has more than one primary key: CREATE TABLE {node_field_data}
.....
.....

dcrocks’s picture

Because of the changes since #67 I rerolled the patch so it applies without warnings.

Edit: this is a quick and dirty fix just to get SQLite installed. -chx

dcrocks’s picture

Status: Needs work » Needs review

needs review

Status: Needs review » Needs work
Issue tags: -D8 upgrade path, -D8MI, -sprint, -language-content, -Needs upgrade path

The last submitted patch, node_table_too_many_primary_keys_1998366_93.patch, failed testing.

dcrocks’s picture

Status: Needs work » Needs review

Status: Needs review » Needs work
Issue tags: +D8 upgrade path, +D8MI, +sprint, +language-content, +Needs upgrade path

The last submitted patch, node_table_too_many_primary_keys_1998366_93.patch, failed testing.

Anonymous’s picture

Issue summary: View changes

Restore remaining tasks section.

Gaelan’s picture

Gábor Hojtsy’s picture

Tagging as per discussion with @catch above.

chx’s picture

Please confirm that this revision of the issue summary is up-to-date and #93 has nothing to do with the current compromise and then I might take a stab at implementing this. This is a very, very confusing issue and #93 really doesn't help especially that in the last month none of the esteemed architects hashing this out has uttered a sentence about #93 being desirable or not. Around #50 this issue should've been made a meta and the entity translation re-architecturing moved into a separate issue cos from that point on it's an entirely different issue than before!

dcrocks’s picture

As much as I would like to see this resolved I don't think myself capable to address the issue as it currently stands, or I would have put the effort in long ago. I just want to install D8 on SQLite. The issue was beset initially by other D8 problems that clouded the actual cause of the failure when installing on SQLite. #93 provides a simple fix that allows D8 to be installed on SQLite, but it has never been thoroughly tested. And it was soon adjudged to be inadequate as a permanent solution. Thus the current summary.

Although I use #93 so I can build D8 on SQLite, my feeling, based on post #50 comments, has been that I will run into trouble eventually. So far, the simple things I have been doing haven't raised any new issues. On that basis, splitting up the issue to separate #93 doesn't make sense because #93 will never be committed. But, starting a new issue so as to scrap out the noise in the early comments does.

I do know that D8 is currently uninstallable on SQLite, and has multiple problems with Postgres as well. With other things going on now in D8, I would think an early solution would be better than a late one. My 2 cents.

plach’s picture

@chx:

Yes, the issue summary is up-to-date and #93 is just a quick fix to allow people to complete a D8 installation on SQLite without it blowing up. I did propose to provide here just a quick fix for this bug and address the refactoring in a separate issue, but the quick fix was not deemed adequate.

The refactoring was not planned originally so we ended up here. This was the meta issue, not sure why it was marked as fixed: #1498634: [meta] Define revision/translation SQL schema for core entities (no patch), probably to indicate we had an agreement.

Damien Tournoud’s picture

Yes, the summary is up to date and #93 is not appropriate.

chx’s picture

Title: Improve the database schema of the node entity storage » [meta] SQLite is broken
Issue tags: -API change, -D8 upgrade path, -D8MI, -sprint, -language-content, -Needs upgrade path, -Approved API change

The entity storage fun is continued in #2057401: Make the node entity database schema sensible. We can't have an issue this complicated with half of it talking of something else.

dcrocks’s picture

Thank you. I will wait on #2057401: Make the node entity database schema sensible to close this one. But I will keep the #93 patch applicable because others may have the same need I do.

catch’s picture

Issue tags: +Testbot environments

Tagging.

catch’s picture

Issue summary: View changes

add blocked and related issues

plach’s picture

Issue summary: View changes

Restored original issue summary

nevergone’s picture

I probe install the latest devel version from Git. If the database system is SQLite, then result next error message and install process is broken:

An AJAX HTTP error occurred.
HTTP Result Code: 200
Debugging information follows.
Path: http://drupal8.l/core/install.php?langcode=en&profile=standard&id=1&op=do_nojs&op=do
StatusText: OK
ResponseText:
Home | Drupal
Drupal
Installation tasksChoose language (done)Choose profile (done)Verify requirements (done)Set up database (done)Installation profile (active)Configure siteFinished
Home
SQLSTATE[HY000]: General error: 1 table "node_field_data" has more than one primary key: CREATE TABLE {node_field_data} (
nid INTEGER PRIMARY KEY AUTOINCREMENT CHECK (nid>= 0),
vid INTEGER NOT NULL CHECK (vid>= 0),
type VARCHAR(32) NOT NULL DEFAULT '',
langcode VARCHAR(12) NOT NULL DEFAULT '',
default_langcode INTEGER NOT NULL DEFAULT 1,
title VARCHAR(255) NOT NULL DEFAULT '',
uid INTEGER NOT NULL CHECK (uid>= 0) DEFAULT 0,
status INTEGER NOT NULL DEFAULT 1,
created INTEGER NOT NULL DEFAULT 0,
changed INTEGER NOT NULL DEFAULT 0,
comment INTEGER NOT NULL DEFAULT 0,
promote INTEGER NOT NULL DEFAULT 0,
sticky INTEGER NOT NULL DEFAULT 0,
PRIMARY KEY (vid, langcode)
);
; Array
(
)

Gábor Hojtsy’s picture

@nevergone: yeah that is in fact what should be resolved in #2057401: Make the node entity database schema sensible as mentioned above.

Gábor Hojtsy’s picture

Issue summary: View changes

Updated issue summary.

dcrocks’s picture

I revised the summary to point directly to #2057401: Make the node entity database schema sensible to keep people from tip-toeing thru the tulips here.

dcrocks’s picture

Status: Needs work » Closed (fixed)

#2057401: Make the node entity database schema sensible has landed and it is possible once again to install D8 on SQLite. Closing

dcrocks’s picture

Issue summary: View changes

Point to parallel issue.

geek-merlin’s picture

Crosslinking this issues which makes sqlite still broken for medium and big sites: #2031261: Make SQLite faster by combining multiple inserts and updates in a single query

xjm’s picture

Component: node.module » node system
Issue summary: View changes