This site has been archived and you can no longer log in or post new messages. For up-to-date community resources please visit ezplatform.com

eZ Community » Forums » Developer » Object/node health check
expandshrink

Object/node health check

Object/node health check

Tuesday 01 July 2008 11:55:17 am - 8 replies

Hi there,

Would there be any reliable method of checking if a content object of given ID and its nodes are in a consistent shape? For example, by querying the database and checking if certain columns have proper values, that certain relations exist, etc...

Thanks,
Piotrek

Modified on Friday 04 July 2008 6:50:09 am by Piotr Karaś

Friday 04 July 2008 1:03:57 pm

no sorry doesn`t exist yet

Friday 04 July 2008 1:29:57 pm

And that goes for the whole database. There are no sanity check utilities.

Friday 04 July 2008 1:50:10 pm

Do you guys mean: they haven't been put together yet or they are impossible to come up with? blunk.gif Emoticon

Friday 04 July 2008 3:06:27 pm

I'm quite sure it's not a question of it being possible, but complexity might be an issue.

I think part of the problem would be solved if there were constraints to make sure there is at least referential integrity. Too bad MyISAM is around or it would be possible to add contraints.

Friday 04 July 2008 4:17:57 pm

Took me a while to find it, but the closest thing I know about is this:
http://ez.no/developer/forum/general/problem_corrupt_contentobjects

Modified on Friday 04 July 2008 4:18:16 pm by André R

Saturday 05 July 2008 1:46:40 am

Thanks, André!

I think part of the problem would be solved if there were constraints to make sure there is at least referential integrity. Too bad MyISAM is around or it would be possible to add contraints.

Actually - we only use InnoDB, but no constraints seem to be there out of the box. Shouldn't transactions take care of the problem, though?

Cheers,
Piotrek

Monday 07 July 2008 7:17:05 am

Actually - we only use InnoDB, but no constraints seem to be there out of the box.

No, because (a) eZ Publish started with MyISAM only for MySQL and (b) I think MyISAM is still supported.

Shouldn't transactions take care of the problem, though?

Transactions say nothing about the data entered. It's just a protection in case it goes wrong so you don't get half of the data in the db while the other half failed. As long as all database conditions are met (not null columns, datatypes, query syntax, ...) there is nothing to stop bad data from going in.

To illustrate the difference:
You create your own query to add a row in the ezcontentobject_tree table and you wrap it in a transaction. Unfortunately, you introduced a bug somewhere in the code resulting in multiplied parent node ids (which is a foreign key in that table). Two situations: node id A is double of its expected value, but still exists in the db; node id B does not exist at the moment.

The database with only transactions:
- A: The query will be executed and the row added
- B: The query will be executed and the row added

The database with transactions and foreign key constraints:
- A: The query will be executed and the row added
- B: The query will be executed and will fail, triggering a rollback due to the transaction.

So you can see that contraints don't give full protection, but they do take out bogus entries where foreign keys would point to a big void. They also come into play when you're deleting stuff to make sure the database remains in a consistent state.

Monday 07 July 2008 8:00:00 am

Hello Hans,

From what you described, what I had known about transactions and constraints was quite right. You're right though - constraints would provide additional level of bogus data elimination, even though I guess in order to have a complete integrity, everything would have to be constrained and isolation level would have to be raised to serializable, right? Wouldn't this all make db heavy and "picky"?

Just to compare the practices, in my own code I used to run my own PHP-level integrity checks, and manually rolled-back, even if DB would allow commit on the physical level. Of course, I realize that would only be a slight enhancement, not a replacement of constraints.

Last thing. Isn't there another reason for which constrains aren't used? I've heard of this approach for application architecture where db, which uses the smallest possible amount of functionality of particular db engine, serves merely as a data storage, and all other functions and integrity are controlled by the application layer. We now hear more eZ Publish supporting more database engines, isn't that a mean of being able to deliver that?

Thanks,
Piotrek

expandshrink

You must be logged in to post messages in this topic!

36 542 Users on board!

Forums menu

Proudly Developed with from