fragmenta / fragmenta-cms

A user-friendly CMS written in Go (golang)
http://fragmenta.eu
MIT License
586 stars 70 forks source link

I can't pass null value to database #36

Closed shahendaeldeeb closed 6 years ago

shahendaeldeeb commented 6 years ago

Whenever we have null value that needs to be persisted in database, the map in pages.Update() prevents as from doing so as the type of the map to be persisted is map[string]string and such map doesn't accept null as value We think that if it was implemented map[string]*string/ map[string]interface this would get over this issue. Thanks in advance

kennygrant commented 6 years ago

If you simply omit it from the map, it should remain as null (it if was already). If you want to explicitly set a col as null in exceptional circumstances you should be able to use raw sql to do so?

I prefer keeping this stringly typed to make it very clear that it doesn't make decisions on types at this level, and to allow interop with json (I juse the same functions to vivify resources from json as from the database). I don't use database nulls much (if at all), and am happy with the zero value in place of null, but am aware this is a tradeoff that might not suit anyone.

Can you explain a little more about what you're using nulls for in this case?

shahendaeldeeb commented 6 years ago

first thanks for your reply , here is the scenario , i have editable multi level menu items ,i can drag menu item from second level to first , so i need to explicitly set its parent_id to NULL . using the raw sql just to support null might not be the best practice, what do you think ? also zero is a value so we can't use to as replacement for null. i think it wouldn't be confusing if i uses map[string]*string , as it will point on either string value or null , we just need to extend the map to support null.

kennygrant commented 6 years ago

This was a design decision to simplify usage, though I accept it might not suit everyone.

I rarely use nulls as I think they cause a lot of problems (see the billion dollar mistake), though there are cases where you need them. In the case above I would use parent_id 0, not parent_id null to mean the same thing, and default the column to 0 - I am doing exactly this in a few apps and it works fine (hierarchy of tags, parent_id set to 0 where no parent).

I explicitly wanted the boundary of conversion to types to come after params within actions, to make sure people don't pass around bogus types by mistake.

So I think I'll close this one, after some thought, I would rather not do this. Thanks for the suggestion though and please do fork to try it out if you like and let me know how you get on. I'd also be interested if you try using parent_id 0 though - that works for me but perhaps I'm misunderstanding.