I am trying to use ARGen to access a DB Model for SQLite3 created in valentina. As I would like it to be “scalable” later towards MariaDB I introduced “ID” fields as string GUIDs. The GUIDs are generated fine (using MBS plugin). However, whenever I try to add or update a record using the “environment” generated by ARGen, a new record does not get a GUID, and any edited record gets “duplicated” without its GUID.
Has anybody encountered this behavoir before? Is this something I missed to “fix” using the right “parameters”, or is this just (one of) the weakness of this plugin? I never tried to use “integer autoincrement” or such (and I am not inteding to do so). The problem seems to be in “IsNew” method, but I am not sure.
And no, because I am using argen and xojo “out of the box”, no examples are available (thank you for your deep investigation readiness), I really would just like to ask about your experience and about your changes to ARGen source code regarding my problems… Maybe I am on a completely “dead track” with ARGen?
The integer autoincrement seems to bare conflicts in the scaled-out version of this db-model. When I have several (decentralized) sources of “unique” ids, I might earn conflicts I would not like to be forced to handle (some “sites” might create an ID of “101” or such). “Combined indexes” might soone become “too expensive” to be handled.
It’s been several years since I’ve played around with ARGen but IIRC you have to implement the event for Create (maybe BeforeCreate?) and manually give it the GUID value. In a similar way as you’d enter the Created value for a new record and Modified date for an updated record.
If that’s what you’re doing then you’ll have to dig through the debugger to determine what’s causing it to be undone.
For things like web services GUID is considerably preferable to an Auto increment ID column. GUID’s (should) never repeat. GUID’s aren’t as easy to read and there are performance issues with them but I’m working on a micro-services project where they are essentially the only way we can work with a database.
The integer autoincrement seems to bare conflicts in the scaled-out version of this db-model. When I have several (decentralized) sources of “unique” ids, I might earn conflicts I would not like to be forced to handle (some “sites” might create an ID of “101” or such). “Combined indexes” might soone become “too expensive” to be handled
Unless you are build something like an international stock trading system with thousands of users, you won’t have a problem with auto generated ids. Replication services in the various DMBS systems have solved that problem plus a whole lot more you have not thought of a long time ago.
And even if you do need such a solution, generating GUIDs is not the answer. All it will do is ensure that you can write a record to a table, it won’t prevent you from having duplicate entries and is error prone when the rubber hits the road and users have to work with them.
Thanks, Bob, for your reply. I am doing exactly what you suggest, and the GUID gets generated just fine. A record does get stored, but the primary key field remains empty (the GUID value can be written to another field with no problems, though). There are methods for UpdateRecord and InsertRecord, but the latter is never being run. I think I‘ll have to bite the bullet and go through the debugger line by line in my case.
I was hoping somebody had already run into this problem and has already solved it.
I found my problem and a solution for it. First, I was looking in the wrong “InsertRecord” Method. There seems to exist an “override” for each DatabaseAdapter Class. Second, in the correct method the Primary Key field is handled very special, i.e. it is explicitly omitted from “normal processing” like all other fields.
I added a new Constant that can be used to decide wether to continue to use this “special treatment” or not (i.e. using String GUIDs in PK fields). And that does the trick!