Editor not updating Datatable after create ...
Editor not updating Datatable after create ...
Hiya ...
I'm wrestling with an odd problem.
I'm using Editor 1.6.2 and dt-1.10.15 from cdn.datatables.net on Apache/MySQL 5.5/PHP
I have a table of "Users" that has an auto-inc integer Id column that MySQL requires be the primary key. I also have an insert trigger on the table that creates an entry in a UUID column. I'd prefer to use the UUID column as the primary key for datatables/editor just to obfuscate the DTRow_ID a bit but MySQL won't allow it to be a primary key in the presence of an auto-inc primary key. I'd like to keep them both because I use the Id column to make internal junction tables more readable.
When I instantiate an Editor in the ajax php with ...
Editor::inst( $db, 'usr_Main', 'Id' )
... a new record is returned by ajax to the Datatable when created as expected.
When I instantiate an Editor in the ajax php with ...
Editor::inst( $db, 'usr_Main', 'UUID' )
... a new record IS NOT returned to the Datatable on creation by ajax. However, if I refresh the page, the new record then appears so it has been created properly. It just doesn't get returned through ajax. I'd like to avoid having to refresh every time a new record is created.
Any thoughts?
Dave
This question has an accepted answers - jump to answer
Answers
Hmmm ... I noticed that I asked this same question a little over a year ago and got a great answer from Allan so I go with that unless there's been any changes ...
Cheers!
Dave
Hi Dave,
You are correct, my answer from before still stands. The libraries are basically just getting the primary key value, and since that isn't the value that you want, there is a bit of a problem.
In the Oracle integration I haven't actually found a good way to get the primary key for a table, so it does use the primary key name that you give the Editor instance initialiser, rather than doing it automatically, which would resolve the issue you are seeing. But that presents issues when attempting to edit a joined table, since it would continue to use that same primary key name, which is likely wrong!
That's the direction that I'm going to try and take that aspect of the libraries though. So if you ask in another year, that might be the way it is then implemented ;-).
Allan
Hi Allan,
Thanks for your prompt response. Much appreciated!
Running into the problem again has led me to start thinking about the way I'm structuring my tables and I'm now considering and testing using a UUID as a primary key for all tables and doing away with an auto-increment integer. Currently, I'm using Datatables and Editor in an internal CRM type of application but am looking at building it out to offer as a service to other companies in our industry and want a way of obfuscating the row Id so keys aren't easily "guessable". That, and some type of .min and obfuscation strategy for the .js files seems to me to be the first step in strengthening the basic security of things.
Thanks again for your help!
Dave
Perhaps one option would be to use the UUID as the primary key?
Having said that, if someone could do something bad by guessing an id, they could also do something bad by guessing a uuid. It might take them longer to guess it, but it isn't really security in my mind.
Allan