cash wrote on 39886548-03-16

These lines demonstrate the problem:

$CONFIG->db->split = true;
$CONFIG->db['read']->dbuser = "";

As described in the ticket, $CONFIG->db->split would need to be changed to work. database.php would also have to be updated.

This is related to ticket #1377

trac user obito wrote on 39891041-10-30

Replying to cash:

These lines demonstrate the problem:

{{{
$CONFIG->db->split = true;
$CONFIG->db['read']->dbuser = "";
}}}

As described in the ticket, $CONFIG->db->split would need to be changed to work. database.php would also have to be updated.

This is related to ticket #1377

Cash, you explain so little, what do i need to do? i renamed "$CONFIG->db->split" to "$Config->connection->split" in both settings.php and database.php and again i got nothing.

Please explain what exactly i need to do, this is driving me crazy and would really appreciate it.

cash wrote on 39892074-02-24

Split databases is not implemented in the core. It looks like early on for Elgg 1.* they were considering it, but I see no evidence it was finished and tested.

trac user obito wrote on 39892815-10-18

Replying to cash:
so it never really was finished on elgg 1.5, I bring this up since in MySQL this

SELECT m.*, n.string as name, v.string as value from elgg_metadata m JOIN elgg_entities e ON e.guid

is slowing down my database, i think i have too many tags and it slows down elgg when they look it up. Does elgg have any solution for this?

cash wrote on 39896189-05-06

Yes, it is not finished.

About your question, this is not a support forum. This ticket is about read/write connections. To find help, I suggest you try the community site. Good luck.

Milestone changed to Elgg 2.0 by brettp on 40088130-06-23

Milestone changed to Future Release by cash on 41784028-04-16

trac user srokap wrote on 42821723-03-19

Pull request fixing this ticket: #410
The feature seems to be almost in place, that's a shame to leave it with bugs. All core tests are passing on this version.

Based on discussion in #6197, this feature should now be working fine.

Hello,
I understand I may not get an answer to my question below, but just in case someone can confirm (or infirm) that the particular issue I am describing below does not happen anymore:
Way back then (in 2008), I set up a system using a master/slave DB system. It was working fine except for one thing: every so often, I would end up with a weird entity with user subtype but no associated entry in the users_entity table. After debugging, I realized the issue had to do with the fact that the user creation was a two-step process whereby the entity would first be created; once the guid for the entity was obtained, the user creation would then be completed. But, in my master/slave system, because the replication was not always fast enough, the new GUID would sometimes not be available from the 'read' handle and the second step would then fail, leaving a half finished entity in the entity table.

The write connection returns the last insert ID, do we actually do a read between the two inserts?

As far as I can tell:

• User is created via register_user (line 316 in engine/lib/users.php)
• register_user calls user->save() (line 429 in engine/classes/Database/UsersTable.php)
• The entity save function is a two step process whereby the entity is first created, the guid of the entity is then read and the second part of the creation is then triggered (line 1466 in engine/classes/ElggEntity.php)

Let me point out that I have not tested this with the new version. As mentioned above, I experienced this problem in 2008. However, since one of the projects I am working on is planning on using this split DB architecture, I am trying to make sure this was solved.

Digging more into the code, I think I found my answer:
create() (used to returned the GUID in the entity save() function) uses the insertData() function (line 231 in engine/classes/Elgg/Database.php); and insertData clearly uses only the 'write' handle.
So I think everything is peachy.