Has anyone needed a bigger TEXT-field ? In my schema I need a >65k sized text-field, but whenever I try to set Database Type to longtext or mediumtext, it defaults to string/varchar(0).
How can I store bigger texts than 65k ?
Dag,
Looking into this for you and have reached out to you via email, as well. We will figure this issue out for you and give an update here shortly.
Thanks,
- Mark
Dag,
Did you have success here?
I wanted to point out that you may have to use binary data type - shoot me an email.
Thanks,
- Mark
Nope, no success on this issue yet.
Hi guys, did this ever get resolved? I’m having exactly the same issue.
Hey Antony, I’m looking into it. I’ll post an update once I have more info.
Thanks Ben.
I’ve noticed a few quirks in the Schema management area for the internal DB, mainly that some of the settings refuse to persist when updating. I’ll try to summarise any issues if I get chance tomorrow!
On a related note, does DF keep a summary of the settings internally somewhere too? I’ve attempted to amend some of the schema directly in mySQL but these changes weren’t reflected in the web interface so switched the config back to avoid any unexpected behaviour.
What version of DSP are you on now?
The schema settings for the native MySQL db are stored in JSON format. The JSON editor for managing schema in 1.7.8 should make schema management easier. The UI should be picking up schema changes you make directly, not sure why you’d be seeing that behavior…let me know if you’re using 1.7.8.
Hi Ben,
So you’re saying I could just set the mysql datatype to LONGTEXT in the JSON-editor in the schema settings to override the defaults ?
I did this for a quick test in my 1.7.8,
"type": "string",
"db_type": "longtext",
After successfully updating the schema, its still this;
“type”: “string”,
“db_type”: “varchar(0)”,
let me look into it.
You found a bug. We’re fixing it and will post once a fix is ready. Thanks.
1 Like
Looking forward to the fix! 
FYI I’m getting another similar issue related to decimal fields. It refuses to accept my setting and always seems to default to 11,0 or 10,0 in the database type.
Antony
Lee may be aware of this, I’ll confirm. Thanks for letting us know!
I’m also seeing this. To be honest, the whole schema-editing part is very flaky atm. If i have several fields that should have type string/text, and I edit one of them, ALL text-fields is set to string/varchar(0) which also conveniently truncates all my data.
Before touching the Schema-editor I now have to backup the db, do the editing-ritual in the right order, and then restore the data.
Still, all in all I think you guys are making something good and have implemented alot of great ideas 
/Dag
@dag I’ve found editing the schema in something like phpmyadmin works quite well. DF won’t necessarily see changes you directly make immediately (I’m assuming some caching must be involved) but it does pick them up eventually (including related data). I might initially create a table using the editor so I can add the DF specific fields such as ‘user id on create’ then expand on it in another editor.
I think this’ll be much easier than your current approach!
1 Like
@dag and @antonyjsmith Just a quick update, I have confirmed and fixed quite a few of these issues. They are slated for the next release hopefully by the end of this week. This will include some fixes for caching schema, as well as, comparing requested changes to what already exists before attempting changes on schema. This is what was causing a good bit of the issues, i.e. the UI (not the API) sends up the whole table config for altering, instead of just the edited parts. I will update this thread when these specific issue fixes are rolled out.
Yeah, I also previously did alter the databaseschema manually in mysql, but this approach screamed wrong approach, so I tried the best I could to do the right thing
@dag @antonyjsmith 1.8.0 has been released on github. The free hosted system and Bitnami images will be updated in the next day or so. FYI, we added Oracle support in this release as well!
Try out the new schema manager UI. You will notice that now, if you want to use one of our “simplified” types, select it from the Type dropdown, otherwise select ‘I will manually enter a type’ and enter your db-specific type along with any additional parameters (i.e. varchar(80) or mediumtext, etc). Also, the server side is smarter at determining what is really a schema change and should not mess with “unchanged” schema. Upon completion, you will see the server should stick with that type for “Database Type”, while the “Type” field will show the closest simplified type it adheres to (this is to make clients jobs of building live forms easier - see our Data Manager).
As always, let me know if you have further issues or questions.