No Default

[Midnight Modding]

What's the deal with a form not working in the acp, due to a db exception saying "no default value" for a text column, then in db schema we can't even "put" a default value for a text column? Even changing it to allow null doesn't change default to null.

[bfarber]

Why can't you put in a default value?

[Midnight Modding]

44 minutes ago, bfarber said:

Why can't you put in a default value?

In database schema, any time I select "text" for the column type, the "default" input no longer shows on the form. It does it for any text types. (the form field being hidden). So hardly any of my app will work because a lot of times in 3.x (as I saw done by first party apps, I believe), I put no default for text columns.

[newbie LAC]

8 minutes ago, Midnight Modding said:

In database schema, any time I select "text" for the column type, the "default" input no longer shows on the form.

https://dev.mysql.com/doc/refman/5.7/en/blob.html

Quote

BLOB and TEXT columns cannot have DEFAULT values.

 

[Midnight Modding]

Just now, newbie LAC said:

https://dev.mysql.com/doc/refman/5.7/en/blob.html

 

Then why is it givng me an error saying the column has no default? I can't use the form due to it.

I assumed from the beginning text can't have default, but that's the error I get when trying to save my form.

[Adriano Faria]

Just don't add a default value (ALLO NULL enabled) and make the field REQUIRED. If it's the content, it HAS to be required anyway.

[newbie LAC]

1 minute ago, Midnight Modding said:

Then why is it givng me an error saying the column has no default? I can't use the form due to it.

I don't know. What version you use?

[Midnight Modding]

edit

[Midnight Modding]

edit

[Midnight Modding]

Btw, in my db schema for forums and other first party apps, it says my db version doesn't match the schema one... I wonder why that is? I have the latest version of files and dev files.

On a side note, though, as far as text columns not allowing defaults, the db schema says some text columns in forums have default of null, but maybe it's some hiccup with the listing?

[Midnight Modding]

Realized me unsetting the $values, due to them being translatables, was the problem. So it had nothing set to store in the columns, which are still there from 3.x because I have to move their data. So I have to temporarily make it set them to empty strings where I can test without dropping the columns yet.

I'm going to have some weird db tables if I use translatables how I have them. One table will have only a primary id and a position id and that's it... because the rest are translatables.

Should I really go to the trouble of converting all of my old columns' values into the translatable system? I guess I pretty much have to for editing old ones to work without me adding a lot of extra code to the forms. I'm on the fence as to whether I am going overboard even doing so many translatables in the acp because some of these aren't normal nodes.... but I guess it would still be good to have them translatable.

[bfarber]

If it's user-facing text and there's not a legitimate reason not to then yes, they should be translatables. Having a table with just two columns is not a problem.

[Midnight Modding]

23 minutes ago, bfarber said:

If it's user-facing text and there's not a legitimate reason not to then yes, they should be translatables. Having a table with just two columns is not a problem.

You saying that just reminded me actually a few of them aren't ever listed on the front side so i could change those, at least. Very few of them, though.

Also, I have a content item addable from both the admin and front sides, so I assume I shouldn't do any translatable on that table, although... in this custom version he may only have it addable from the acp side.

[bfarber]

Never use translatables on the front end. Not only would it be a confusing experience for most users (who will typically only speak one language anyways), but it can open up security issues because strings stored in the language system tend to be trusted throughout the code as safe (and user-submitted input from the front end is most definitely not safe).

[Midnight Modding]

ok thanks. I really wasn't intending to do it, anyway.

[Midnight Modding]

I'm still really confused what had caused that original sisue...

		if ( !$this->id )
		{
			$this->save();
		}

I had that in formatFormValues() BEFORE I had been unsetting the $values for the translatables. So it was already calling save() while still HAVING values for the text fields. So i have no clue why this even got fixed by me commenting out an unset line AFTER that save() would have been called.

[Midnight Modding]

I guess the fix was never related to me unsetting anything... as that was after the save().

I see I had changed the column in the schema to allow null. So I guess that is what fixed it... So for a text db column, if it allows null, it doesn't give an error if you don't set it to anything in an insert, but if it doesn't allow null, it will have that error?

edit: yeah, Looked it up... just never realized allowing null gets around that issue.

[Midnight Modding]

Sigh. My problem overall isn't just text columns, it's anything where the form default value is null and they don't enter anything. So I need to go changing every varchar and text column to allow null if it's not a required field on my form, apparently... I really don't like using null much because I think of null as "unknown", but on a form if they don't enter anything it would be "nothing", not null. And I don't really want to waste time changing null to an empty string for varchar fields, either, bad of course for text ones I MUST  have it something other than an empty string.

[CodingJungle]

4 hours ago, Midnight Modding said:

I really don't like using null much because I think of null as "unknown", but on a form if they don't enter anything it would be "nothing", not null

null literally means "relating to zero" or "amounting to nothing" or "having no value". in most programming language its used as "having no value", so if they enter nothing, it would be "having no value". null value is also treated differently in php, other than empty values or booleans, so in your code, they could trigger different things.

4 hours ago, Midnight Modding said:

And I don't really want to waste time changing null to an empty string for varchar fields, either, bad of course for text ones I MUST  have it something other than an empty string.

use the form helpers "validate" and "required" options if you MUST have data, the form wont submit, it will throw an error and force them to fill them in. you can also get a bit more advanced by using appearRequired and then using a custom validation.

 

also keep in mind, if you plan on doing translatable fields, you will need to be able to do $model->save() to create placeholder record, so you can use $model->id to do a custom lang string for 'em, so you might really want to consider allowing null, or setting a default value, cause when mysql strict mode is enabled, trying to save a record to a field that doesn't have a default value or allows nulls, will throw an error.

[Midnight Modding]

2 hours ago, CodingJungle said:

null literally means "relating to zero" or "amounting to nothing" or "having no value". in most programming language its used as "having no value", so if they enter nothing, it would be "having no value". null value is also treated differently in php, other than empty values or booleans, so in your code, they could trigger different things.

use the form helpers "validate" and "required" options if you MUST have data, the form wont submit, it will throw an error and force them to fill them in. you can also get a bit more advanced by using appearRequired and then using a custom validation.

 

also keep in mind, if you plan on doing translatable fields, you will need to be able to do $model->save() to create placeholder record, so you can use $model->id to do a custom lang string for 'em, so you might really want to consider allowing null, or setting a default value, cause when mysql strict mode is enabled, trying to save a record to a field that doesn't have a default value or allows nulls, will throw an error.

edit: I didn't realize that I had asked in here about save() to get that id, so that's why you brought that up. I figured that all out long ago. In fact I referred to why it's done just yesterday, but then edited it out and the topic was deleted, I believe.

All of what you just said, I already knew. I've done a lot of forms. I know about required, validation checks, difference between the behaviors of null and empty strings and all of what you just said. I know null is the same as "nothing", technically, but I was just saying some people think of it as "unknown" or "nothing, for the time being" also. I remember it described that way years ago in some tutorial. For instance, if a column stores an address, null would not mean the person has no address, it would mean they have no data for it. And I just didn't like using null over the years, anyway.

I know "how" to do it. I could either set defaults to empty strings, do checks after the form is submitted and change null to empty strings, or I could alter the columns and allow null. I was really just randomly rambling in here about having a hard time deciding which I wanted to do.

I appreciate you trying to help, though. I just am further along than you and aiwa always assume. I'm pretty much done with the app other than bug fixing and the upgrade routine. So i've obviously learned everything about 4.x and some php I hadn't needed to know before (just yesterday learned about passing by reference, for instance, as I hadn't needed to do it before. lol.)

Anywayyyyy so I'm where I need to be on about everything now. I was mostly just deciding which way to do this and shouldn't have even posted it, as it's just a personal decision.

I've done a lot of overriding methods, made my own table classes, trimmed thousands and thousands of lines out by reusing the same code when possible, etc... I've finally got it close to how I want. It's one massive app, though, so I am beyond ready to be done. It's a lot bigger than the public version.

ps what you really need to be doing is convincing me between 8700 and 2700x. ? I'm down to just cpu and mobo and there are reasons to go either direction.

[Midnight Modding]

In case anyone cares to know what this was truly all about, after all of my rambling, it was all about fields that i do NOT want required, but in 3.x I had them set as not null, so was getting errors, not just for text, but also varchar, because I had the form defaults as null. :)

[CodingJungle]

8 hours ago, Midnight Modding said:

All of what you just said, I already knew.

I wasn't exactly replying to you, i was replying to any future people who might stumble across this babbeling brook of a thread, and might mistake or misunderstand what you said as "correct". in what you had wrote, it was clear that you knew nil about null. 

[Midnight Modding]

2 hours ago, CodingJungle said:

I wasn't exactly replying to you, i was replying to any future people who might stumble across this babbeling brook of a thread, and might mistake or misunderstand what you said as "correct". in what you had wrote, it was clear that you knew nil about null. 

And, as usual, you were wrong on your assumptions. No surprise there.

[CodingJungle]

17 hours ago, Midnight Modding said:

I really don't like using null much because I think of null as "unknown", but on a form if they don't enter anything it would be "nothing", not null.

 

3 minutes ago, Midnight Modding said:

And, as usual, you were wrong on your assumptions. No surprise there.

your words spoke for themselves, i'll let other decide. 

[Midnight Modding]

Took me 2 minutes to find someone considering it the same way I just described and that is not where I originally saw it. Guess what, smart guy? There are many reasons for why someone may choose to use null, and using it as a replacement for "unknown" is a common, and valid use.

https://dba.stackexchange.com/questions/59/when-to-use-null-and-when-to-use-an-empty-string

Quote

I tend to prefer to use NULL to mean that the value is unknown or not given.

Better go chase that guy down and tell him he's wrong in his usage choices. Better also contact well known sites who use it the same way.

Also, your most important bad assumptions were that I don't know what null IS or how it's treated vs. an empty string in php. But I really couldn't care less what you do think,m tbh.

And, in MY case I never cared to use it. But, since IPS was usually defaulting form values to null, I did it the same way and never even tested with an empty string to see if the built in validation checks would change it back to null or not.