4 ms·
A question for Domino developers: "There is never a question of where the logic for an application is, it's in the same database as the data." - this caught my
by theamk 2y ago
A question for Domino developers: "There is never a question of where the logic for an application is, it's in the same database as the data." - this caught my eye, how did this work?
Specifically, say there is an existing app with many users and which is full of data (say travel planning app) and you need to add a feature to it, which maybe takes a week of dev time.
- Do you work in prod and hope you don't break the existing functionality for users? Maybe even copy all forms ("new-request" -> "new-request2") so people don't see WIP... or maybe do all the work during nights?
- Or do you make a copy of that NSF file to your computer and develop on it? What if it has gigabytes of data, or if it has private data (like that HR database)? What do you do when you done - can you somehow merge code from one NSF file to another but leave data intact?
- Or is this something else? Maybe single-file was optional and big databases were manager separately, or there is some other simple option I am overlooking...
- nradov 2y agoDomino had a concept of template (NTF) files. You could develop in those and apply them to a test environment. Then when development was complete you could refresh the designs of the production databases using the templates, with little or no down time. The problem was that the NTF was a big binary file. You couldn't really do effective team development with branching and merging of source code. We worked out some manual processes for copying and pasting pieces around to prevent conflicts, but it was a huge mess. IBM never really understood or prioritized the needs of Domino developers.
- pjmlp 2y agoIt works the same as in Oracle APEX, and similar systems https://apex.oracle.com/en/ https://apex.oracle.com/en/ You have migration scripts, and also have local copies, or team specific schemas, with dummy data for development purposes. Delivery into production usually done in multiple steps, introducing the new feature, deprecating the old one, and eventually removing the old code/tables in another deployment cycle after the new one proves itself working without issues.