Object/node health check

Next topic

Author	Message
Piotrek Karaś	Tuesday 01 July 2008 2:55:17 am 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 -- Company: mediaSELF Sp. z o.o., http://www.mediaself.pl eZ references: http://ez.no/partners/worldwide_partners/mediaself eZ certified developer: http://ez.no/certification/verify/272585 eZ blog: http://ez.ryba.eu
Björn [email protected]	Friday 04 July 2008 4:03:57 am no sorry doesn`t exist yet Looking for a new job? http://www.xrow.com/xrow-GmbH/Jobs Looking for hosting? http://hostingezpublish.com ----------------------------------------------------------------------------- GMT +01:00 Hannover, Germany Web: http://www.xrow.com/
Hans Melis	Friday 04 July 2008 4:29:57 am And that goes for the whole database. There are no sanity check utilities. Hans http://blog.hansmelis.be
Piotrek Karaś	Friday 04 July 2008 4:50:10 am Do you guys mean: they haven't been put together yet or they are impossible to come up with? ;) -- Company: mediaSELF Sp. z o.o., http://www.mediaself.pl eZ references: http://ez.no/partners/worldwide_partners/mediaself eZ certified developer: http://ez.no/certification/verify/272585 eZ blog: http://ez.ryba.eu
Hans Melis	Friday 04 July 2008 6:06:27 am 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. Hans http://blog.hansmelis.be
André R.	Friday 04 July 2008 7:17:57 am 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 eZ Online Editor 5: http://projects.ez.no/ezoe \|\| eZJSCore (Ajax): http://projects.ez.no/ezjscore \|\| eZ Publish EE http://ez.no/eZPublish/eZ-Publish-Enterprise-Subscription @: http://twitter.com/andrerom
Piotrek Karaś	Friday 04 July 2008 4:46:40 pm 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 -- Company: mediaSELF Sp. z o.o., http://www.mediaself.pl eZ references: http://ez.no/partners/worldwide_partners/mediaself eZ certified developer: http://ez.no/certification/verify/272585 eZ blog: http://ez.ryba.eu
Hans Melis	Sunday 06 July 2008 10:17:05 pm 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. Hans http://blog.hansmelis.be
Piotrek Karaś	Sunday 06 July 2008 11:00:00 pm 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 -- Company: mediaSELF Sp. z o.o., http://www.mediaself.pl eZ references: http://ez.no/partners/worldwide_partners/mediaself eZ certified developer: http://ez.no/certification/verify/272585 eZ blog: http://ez.ryba.eu