In this Wiki you can freely and easily tell what YOU LIKE about DaDaBIK, what YOU DON'T LIKE and what YOU PROPOSE for the future releases.
The Wiki is open to anyone, registration is not needed to edit. If you prefer you can register and login, in that case you can also easily sign your edits.
After six weeks since its opening (wiki opened on February 15, 2011), one of the proposals will be chosen; through the Wiki the DaDaBIK developers together with the users will discuss about high-level aspects of its implementation and finally the developers will implement the proposal as a new DaDaBIK feature.
April 8th, 2011 UPDATE! The feature chosen is the locking mechanism during edit! This feature will allow multiple users to access the same record in edit mode without loosing data. Here is a partial and short description of how the feature will be implemented. Please participate in the wiki writing your own opinion about the implementation! Registration is not mandatory to write.
April 26th, 2011 UPDATE! The Wiki is now closed
- Why a locking mechanism is useful? Imagine user A and user B opening in edit mode the same record about a product. Both the users modify the price, user A from 50 euros to 60 euros, user B from 50 euros to 70 euros. Imagine that user B clicks on the save button a few seconds after user A. Both the users would think to have correctly modify the price, but user A is wrong, the current price is now 70 euros.
comment added by Wolf: Note that this can happen even if A and B edit a different field in the same record. Changes by A will be lost, because B overwrites them with the old data!
- How the feature will be implemented?
1) When a user enter a record in edit mode, the record will be “locked” by DaDaBIK. A table dadabik_locked_records will keep track of all the records which are currently locked by storing a (table_name, primary_key_name, primary_key_value) triple, which allows to identify a single record in a DaDaBIK installation, and the username of the user.
2) If a user leave the edit mode clicking on any links in the DaDaBIK interface, the record will be unlocked by deleting the relative entry from the dadabik_locked_records table
3) If a user enter a record in edit mode and this record is already locked, a message will be displayed (e.g. “This record is locked by user x, you can view it but you can't modify it, refresh the page to know when the record status will change to unlocked”) and if the user try to save it, the changes are not token into consideration.
This is all for the moment. One (but probably not the only) thing I'm not sure how to handle is the automatic unlocking: e.g. if the user A enters a record in edit mode and then go away from his PC the record can remain locked forever. How do you think this should be handled? — Eugenio 2011/04/08 20:50
Hi Eugenio, congratulations and thanks for this choice! Having proposed this feature, I think this will vastly expand DaDaBik's potential user base. About your question how to handle unlocking. My suggestion is to give every lock a time stamp, and only locks younger than x minutes are respected. Therefore, no explicit forced unlocking is needed, the lock simply expires if a user never hits “save”. Any expired lock will automatically be cleared if somebody else edits this record and hits the “save” button. I am not sure how difficult it is to implement, but it would be nice for every editing session to see a count down of the time left for its lock, i.e. a display “x minutes left in this editing session” updated say every second. One could also add a button “I need more time for my editing session”, which resets the time stamp to the current time, and of course also reset the count down. — Wolf 2011/04/12 22:45
Hi, the timestamp thing is a smart approach so thanks for the suggestion Wolf; the countdown would probably be too time-consuming (I mean the development) but probably an approach like this could be enough:
— Eugenio 2011/04/13 09:40
Yes, I think this is exactly what we need. Just to be complete:
— Wolf 2011/04/14 09:33
Hi All, Please Add :
— Paval 2011/04/22 05:27
Thanks for the add Paval — Eugenio 2011/04/23 11:26
I like the easiness of the installation procedure — Eugenio 2011/02/14 23:44
I noticed that nobody said what they actually like, including myself. There is always the tendency to take good things for granted. What I like for example, is the simple table format. It is easy to understand. For example, I use my own scripts in parallel to dadabik to insert data - and never hat any problems with it. — Wolf 2011/04/14 9:37
The upgrade procedure, too complicated if you have to upgrade starting from a quite old release. — Eugenio 2011/02/14 23:44
Security model needs rethinking.
CSS needs better documenting.
We miss multiple select! *Tenorife* Yes a multiple selection would be very helpful
The fact that there is no locking mechanism to prevent several users from editing the same record simultaneously. This prevents me from using it in production mode where the data are important. — Wolf 2011/02/15 16:16
You can't add titles to links and show them instead of long url's, and at the same time sort that column by title name.
I propose http://code.google.com/p/wwwsqldesigner implementation (jeanllegros@yahoo.fr)
I didn't know that tool, I'll surely have a look, thanks. — Eugenio 2011/03/11 09:52
Built-in admin approval
What do you mean exactly? — Eugenio 2011/03/04 17:41
Records inserted by the users are not published until the admin has approved (or disapproved) them. I know there are some unofficial modifactions, but this should be part of the official code.
I propose the support for IBM DB2. — Eugenio 2011/02/14 23:44
For us super newbies an Ubuntu repository install John Stirling 2011/02/15
locking mechanism when editing a record — Wolf 2011/02/15 16:16
This is a very good point Wolf, especially enterprise-level applications need locking mechanism to prevent data loss — Eugenio 2011/02/15 17:53
To give dadabik the ability to input data in the same way as nuBuilder does; to be able to manage till millions of records and an advanced search as in PHPMYADMIN.
Do you mean input data directly form the record results table? What kind of problems did you experienced using DaDaBIK with milions of records?
Watch these tutorial on nuBuilder please: http://www.nubuilder.com/index.php?nav=video Cypherinfo
I propose a Global Search Field, it is a thing that lacks so much in dadabik. In the present version have to leave the records screen to the search page and fill the arguments in search fields, it takes too many clicks… It would be much better to have a smart global search of the whole records in one single fiels in the mais page. Celso Ferrarini - Brasil 25/02/11 16:52
This is another very useful feature: I think the best way to implement it would be having the possibility, for each field, to choose if it will be included in the global search — Eugenio 2011/03/02 18:18
In addition to 'to have a smart global search', add a page between hitting the button 'add invoice' and landing on a page with a combobox with 30k invoicenumbers. Add a page like: 'too many records for current selection… please select… give the possibility to divide the 30k in portions of 500 or something. This would dramatically speed up the page for updating an invoice. Johan Roox - Belgium 14/03/11 13:58