I have not used ARGEN yet but I am trying to understand what it does and how it works.
Doing that a thought about how ARgen/ActiveRecord currently organizes the table classes occurred to me.
If I understand it, It looks to me that the current organization in a database module:
DataBaseModule
Classes
Table1Class
Table2Class
does not make it as easy as it could be to work on a morphing database with fields being added ect…
That is because with the events one would either need to implement the events in those classes or use AddHandler somewhere, and sometimes even add more methods or do other modifications to those classes… and that would make generating the class or DB changes and having to redo that stuff more of pain than it needs to be…
One could subclass the generated class and and implement the events and add new methods (or override existing ones) there…
But now you either wind up with the new class having different name, or changing the generated class name, making it private and giving the original name to the subclass… messy
But what if ARgen/ActiveRecord used this organization:
DataBaseModule
Classes
Table1Class (subclass of mTable1Class)
Table2Class (subclass of mTable2Class)
Modules
PrivateClassesModule
Classes
mTable1Class (Only this needs to be replaced)
mTable2Class (Only this needs to be replaced)
I think that way updating for additional fields would be about as painless as possible and while it would add a little overhead, I doubt it would matter…
So for those who have used ARgen a lot, I am I totally off base here, missing something, and if not or would it not be worth the work to do because it is seldom needed?
I think you’re overthinking it. When columns are added to the database the AR classes will detect it and warn you (in debug). All you have to do is add the property to the class. In later versions Tim added the ability to detect when a column was dropped and the AR classes will warn you (again in debug) that you have a property for a column that is no longer there.
For the events, those are at the record level. BeforeCreate, BeforeSave, BeforeDelete and the same things for After. There is a validate event but frankly we never used it much.
When we were using it every day we did the generation of the classes early on and then when a column was added/removed we’d adjust the classes manually. In really large projects where things were in flux we’d generate only the classes we needed at the time and then when we got around to that portion of the code we’d generate the project file and copy the classes we needed into the existing project. So there’s always a fair amount of copy/paste going on. We NEVER regenerated a project because you quickly started adding custom methods and properties into each class.
You could do what you’re saying but I don’t see the benefit of it.
That was the issue I was thinking trying to solve by having all those things in the table subclasses in the organization I proposed above…
My originally thought was that while designing I tend to make a lot of changes to theDB and UI… Need to actually use it a bit to figure out if I need to change either, that is why I thought it might make things easier…
But it sounds you did not find it something that would be helpful…
A couple more questions you don’t mind… I generated a project from an SQLite DB form an old project of mine and it included ALL the adaptors not just the SQLite one… is there a reason for that?
I assume the connection types in ARGEN correspond to Adaptors.
Argen offers connection types of:
CubeSQL
MySQL
ODBC
PostgreSQL
SQLite
But besides the above there are Adaptors for:
MSSQLServer
MSSQLServerMBS
VSQLite (valentina SQLite)
Are they just missing from the list, or are they for DBs that were planned to be supported but never got fully implemented? (that might be a better question for Tim)
Aren’t the “Adaptor Databases” the ones using ODBC? So you would have the ODBC connection type but specific adaptors for the different data bases …? [just thinking aloud based on your description]
It’s been a while since I’ve used ARGen to be honest, but I believe you can delete the database types you don’t need. IIRC there are some constants that allow you to effectively kill their code via #if statements.
I was wondering if they were included so that if you switched DBs but kept the same Table layout, all you had to do was switch the constant for DB type and DB connection info to be able to use the code with the new DB type.
For example you might start out with SQLite but later on move the DB with teh same structure to Postgress .
I’ll look more through the code and see if that looks like it is possible…
Between the prefixes, and a different organization than the way I think, I’m finding it slow going… I have never had to deal with much with OPC.
The other significant one I delved into was Aloe and I found that easier to follow…
I’ll get there with ARGEN too, as I do want to change some things if I can.
As a general comment, looking at the code so far I am a little concerned for some usage cases i can envision about the amount of overhead of the approach… but for most things I’ve done in the past it would have been fine.
I wonder what changes/additions will happen to it from the community now that it is open source… if any!
Well, technically you can switch between databases rather easily as long as it’s the same table/view definitions. In reality I doubt many do that. I know I’ve switched from SQLite to MySQL a few times.
I think you can turn the prefixes off.
One of the big issues with ARGen is that it brings back EVERYTHING in the record. So if you have some big blobs you don’t use very often then put them in a separate table and load as needed. It’s not meant to be fast and efficient just convenient.
I doubt many changes will happen. If anything, I’m kind of hoping that Xojo picks it up and incorporates it into whatever they’re planning. But then again it’s not invented by them so I think they’ll do it the hardest, dumbest way possible.
Feed the table a recordset with a subset of fields in the constructor. Then if one tries to access a field not in the recordset throw an exception and only save the field values for columns in the recordset.
Combine that with a way to generate the field list for the select (so you can use autocomplete to create it and so that compiler can spot errors in the list), and it could be workable.
Another option could be to make fields optionally lazy loadable in the ARGEN config so BLOBs are only accessed when you need them and maybe having a method allowing dumping the data for a field from the record in memory when needed . Then for a save it is treated like it was never loaded as in a partial field list RecordSet case and not nulled).