-
-
Notifications
You must be signed in to change notification settings - Fork 3.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow NULL for #__content columns #4687
Conversation
Copying issue text: Joomla Version: 3.2.2 Error Test Description ','',1,2,'2014-02-11 14:57:35',509,'','1970-01-01 00:00:00','2014-02-11 14:57:35','1970-01-01 00:00:00','{"image_intro":"","float_intro":"","image_intro_alt":"","image_intro_caption":"","image_fulltext":"","float_fulltext":"","image_fulltext_alt":"","image_fulltext_caption":""}','{"urla":false,"urlatext":"","targeta":"","urlb":false,"urlbtext":"","targetb":"","urlc":false,"urlctext":"","targetc":""}','{"show_title":"","link_titles":"","show_tags":"","show_intro":"","info_block_position":"","show_category":"","link_category":"","show_parent_category":"","link_parent_category":"","show_author":"","link_author":"","show_create_date":"","show_modify_date":"","show_publish_date":"","show_item_navigation":"","show_icons":"","show_print_icon":"","show_email_icon":"","show_vote":"","show_hits":"","show_noauth":"","urls_position":"","alternative_readmore":"","article_layout":"","show_publishing_options":"","show_article_options":"","show_urls_images_backend":"","show_urls_images_frontend":""}',1,'','',1,'{"robots":"","author":"","rights":"","xreference":""}',0,'*','') RETURNING id |
Is there a reason why this can be null? As I recall all these columns are json encoded which means that on save at minimum they should have a |
@test - It's working :) |
@test success |
Multiple good tests thanks - setting to RTC |
Of course every item won't. But because it's json_encoded - even a null value means that the actual value stored in the database will NOT be null. See example 2 on the PHP documentation with an empty array http://php.net/manual/en/function.json-encode.php $b = array();
echo "Empty array output as array: ", json_encode($b), "\n"; giving the output
i.e. there's an open close bracket tag The data that Thomas has pasted in above from the original issue shows this.
is what should be being inserted into the images column in this case (even tho all the rows are empty) ditto for the URLs
So setting that it should not be null is not the correct solution to this issue - even if it does provide a temporary solution |
I'm unsetting this from RTC and setting to Needs Review for a bit because I want someone else to look over this. Something is very wrong here for the reasons I described above - and I don't want us to find in 6 months time this masked some horrendous bigger problem |
Thanks @wilsonge Valid point. Needs review. Thanks. |
I agree with @wilsonge This is not the right fix. |
Just not consider only the code perspective,but think also in term of SQL constraints, surely there is a bug on the code side for having a null value on these fields, but the nature of that kind of fields I think is nullable. I agree too more reviews needed |
According to Georges argument, the field never should have a |
Exactly! The fact we have more than just an empty string in the original issue means that something is significantly more wrong. |
Actually, we will have to change type from TEXT to VARCHAR. ALTER TABLE `#__content` CHANGE `images` `images` VARCHAR( 5120 ) NOT NULL DEFAULT '{}'
|
Presumably as people use this on Mysql without any issues day in day out that would be for postgres only tho? |
Yup, this is for example. I will remove alter queries from mysql file, actually whole mysql file and will change postgres alter query with help of @alikon :) |
I just revert MySQL changes. :) |
@@ -0,0 +1,4 @@ | |||
ALTER TABLE `#__content` ALTER COLUMN `images` DROP NOT NULL; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should be
ALTER TABLE #__content ALTER COLUMN images SET DEFAULT '{}';
ALTER TABLE #__content ALTER COLUMN urls SET DEFAULT '{}';
ALTER TABLE #__content ALTER COLUMN attribs SET DEFAULT '{}';
ALTER TABLE #__content ALTER COLUMN metadata SET DEFAULT '{}';
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you should use quotes for the names "#__content", "images" etc.
Guys even so the bigger question is that in the bug report we can see there is data that should be being written to those columns (I highlighted it in my big explanation post earlier) so why does postgres seem to think that big json expression is equal to null? |
this issue arise only on frontend content submission on backend it works as for #3087
|
So in that case can we close this PR all together and fix the malformed json? |
OK So first bug is that when images and urls are turned off we have no images or url fields in the frontend hence why urls and images will throw an error. I guess we need to form a empty blank json variable in that scenario (imo we should do that in the table class tho - as despite it works on mysql it doesn't make it 'right'). With that parameter turned on to show the url and images fields I get the query error above. Note that urls and images appear to have valid json. So I think we can rule out those from our issue list. So now working on spot the syntax error :P |
We can actually do both ways. If you set the correct default value ( |
After reading a bit about this stuff, I came to the conclusion that it's better to allow NULL values for those fields. I'd rather have it consistent across the databases and thus allow NULL in all three supported databases. For our code it shouldn't matter anyway. What do you think? |
I think it's a good idea. 👍 If we agree on it then I will roll back gunjanpatel@170274b changes. |
I would prefer it being nullable. I was tinkering a bit yesterday with that: https://github.com/Bakual/joomla-cms/compare/SqlTextFieldsNullable which would make all text fields nullable in MySQL and PostgreSQL. |
I really still feel like in the majority of cases it is just poor php coding by us rather than cases where these fields should be nullable. |
It's both. Poor database design and poor coding 😄 The better question is: Why should the field not be allowed to have NULL? It makes sense if you define a default value, then the field is (obviously) not going to contain NULL. But if there is no default value, then it should actually be NULL if not defined by code. |
Well theoretically it should be more than just a empty json string. It should contain all the default values of the parameters we are not showing! |
It is not considered bad database design! In general it is not adviced to allow null for any column. At the minimum avoid null for PK, FK, numeric columns and colums involved in query selection criterea. Don't know enough about JSON, but don't like storing empty values there either. There is probably a good reason to waste so much space! |
I agree with that. If possible don't allow null and provide a default value. The typical fields it possibly affects are:
I don't think those are used anywhere as keys or selection criterias. In |
No argument there. Would like Joomla to use the at minimum rule for the database. Let the model decide to respect null values or not. |
Where are we with this one? @Bakual @sovainfo @wilsonge |
Looks like it is @Bakual @sovainfo against @wilsonge @phproberto as in dropping not null constraint vs keeping it. |
I've pinged PLT to have a look.
This PR uses approach 1. |
Having had some time to think about it my argument is that actually to stop null columns being null etc. is exactly the point of the I'm gonna try and get a PR in soon with an example for that in com_content that will also fix the frontend editing there (it's not fixed in 3.4 alpha yet) |
Whipped this up before I go to bed #5230 (note haven't tested it but will do tomorrow) but gives you an idea of how I see we should go |
the basic check #5230 does his job well, is simple, only in a logical place adn fix the #3087 issue |
I still wonder why those text fields are defined as NOT NULL to begin with. Nobody seems to know... |
Well because they shouldn't ever be null. They should have a full json string. Even my thing is a bit of a hacky way around it - really we should pick out all the defaults and store them |
We don't have any default values there. It's all empty by default 😉 |
@wilsonge What makes you say they should never be null. What part of the application requires them to have values. Only when the application requires it the NOT NULL is justified. When implementing the minimum rule as mentioned above these would not be justified. So far all applications can cope with these fields having no value entered yet. That makes the NOT NULL unjustified. |
No I disagree. These are the parameters for the articles. They should always have values. We then have emergency fall backs in the article when we add default values when we retrieve the parameter values (stored in the attribs) doing stuff like Ditto for images. If we aren't showing images then we should have this stored in the database not just guessed at when the entire images column is empty We should only need to define the fallbacks once. And that place is in the form.xml - hence why I stated above my thing is a hack because it doesn't actually solve that problem - although it solves the immediate postgres issue. |
We don't have any default values for images, urls, metadata and attribs. All parameters are saved with an empty value, if anything is stored at all. It absolutely makes no difference if the value in the database is NULL, an empty string or a JSON string with parameters defined with empty values. |
First of all, I object to these attributes of an article being called parameters. For example: images: The business logic of the application doesn't require an article to have images. When no images are provided the application functions just as well. Compare this to the username and email of the user. The business logic within Joomla requires these to be present. A user is considered invalid without them. Those attributes should have NOT NULL. Which makes them required to be entered upon creation of a user. It is not allowed to provide them later. Compare that to images: they can be specified at any time, added or removed. An article is considered valid with or without them. That makes them OPTIONAL, the attribute should allow NULL, respecting the minimum rule! |
Merged this PR as is into |
#__content
tableimages
,urls
,attribs
andmetadata
columns.