183 replies to this topic

[IsNull]

My Class naming comes from languages, which support namespaces. There you try to make short names, as you carry a big overhead anyways.
I didn't realized at a first run, that this is very different here and leads to a huge problem. I'll prefix all Classes with "DBA". Further, I've incorporated finally ADO Support, and I'm currently testing it.

I reconsidered my decision, halting the development on AHK_L scripts will do more harm than anything else. So expect a release soon, I expect some boring lectures this week

Thanks for the reminder anyways

Edit
I've uploaded a first shot of version 1.0, however the 0.9 Version is still online, as the prefixing breaks existing scripts.

[IsNull]

Who moved this thread in here? This belongs to the Custom Section where it was before... :roll:

[infogulch]

Which section would you like it moved to?

Feature request: Allow null values in Insert() and InsertMany() methods. Suggestion: add an empty object NULL to the Database class. (i.e. Database.NULL := Object())This would allow something like:

db.Insert({field1: "abc", nullable_field2: [color=#FF0000]db.NULL[/color]}, "mytable")

Then you can change the field loop to check if the value is an object and if it's equal to Database.NULL, in that case use the literal string NULL without quoting it.

Maybe instead of prefixing with plain DBA, subclass inside class DBA. Though it would require things be in one file :?

Any word on an Update() method?

[IsNull]

Which section would you like it moved to?

Well, all AHK_L related Functions/Classes were moved to the Custom-Section, including this thread. Sombody moved then this thread back, and I literally lost my own thread. :mrgreen:

Feature request: Allow null values in Insert() and InsertMany() methods. Suggestion: add an empty object NULL to the Database class. (i.e. Database.NULL := Object())This would allow something like:

db.Insert({field1: "abc", nullable_field2: [color=#FF0000]db.NULL[/color]}, "mytable")

Then you can change the field loop to check if the value is an object and if it's equal to Database.NULL, in that case use the literal string NULL without quoting it.

This is a very good idea, I'll pick it up.

Maybe instead of prefixing with plain DBA, subclass inside class DBA. Though it would require things be in one file :?

Well, the Classnames lost kind of their readability now, but moving everything in one file is not my style either. Using "DBA_" prefix may improve the readability, but on the other hand, the "_" looks nasty. Partial classes which can be split up over multiple files would be a nice to have, especially to simulate namespaces

Any word on an Update() method?

I guess you're talking about Recordset.Update(), right? Well, the ADO part already supports this, and for MySQL/SQLite I've to look up the primary-key columns from the db, this way it should be possible.

[maul.esel]

Maybe instead of prefixing with plain DBA, subclass inside class DBA. Though it would require things be in one file :?

just a sidenote: ever heard of #Include ? ;-) I use this principle in my ImportTypeLib project as well - only one global object (the ITL class).

[infogulch]

just a sidenote: ever heard of #Include ?

Actually that's what's being done now. Also, could you explain to me how to split a single class into multiple files? Since that was my suggestion, to put everything inside class DBA.

I guess you're talking about Recordset.Update(), right?

Actually I was thinking more along the lines of updating a table. I.e. UPDATE tablename SET field1 = 'something', field2 = 'something else' WHERE primary_key = '123'

Method could be: Database.Update(tableName, record, where, safe = True). The where param would be an object like the record param and would be used to build the WHERE clause. If the safe param is true then the method will first query the primary keys of the table and return if there are any missing in the where list.

Btw, you should put this on github. I would help out.

[maul.esel]

It's now:

#Include <Base>

#Include <Collection>



#Include <[color=red]DBA[/color]DataBaseAbstract>

#Include <[color=red]DBA[/color]DataBaseFactory>



; Concrete SQL Providers

#Include <[color=red]DBA[/color]DataBaseSQLLite>

#Include <[color=red]DBA[/color]DataBaseMySQL>

#Include <[color=red]DBA[/color]DataBaseADO>

#Include <[color=red]DBA[/color]RecordSetSqlLite>

I might have misunderstood you, but I thought of

class [color=red]DBA[/color]

{

    #Include <Base>

    #Include <Collection>



    #Include <DataBaseAbstract>

    #Include <DataBaseFactory>



    ; Concrete SQL Providers

    #Include <DataBaseSQLLite>

    #Include <DataBaseMySQL>

    #Include <DataBaseADO>

    #Include <RecordSetSqlLite>

}

Which is actually more like a namespace. Of course you'll also have to use the DBA. prefix when using the classes, including inheritance. (Note: I didn't test this example, but as I said I'm using the same principle. Hope this isn't going too offtopic. :|)

[infogulch]

Wow I totally didn't even think of that. Looks great to me.

[IsNull]

Indeed a very nice one, maul.esel! I'll do it this way.

@infogulch: I moved the source to github (see initial post). I'll fix the namespace issue soon, and then I can give you write access to the repo.
I think I'll move the explanation to the github wiki, and extend it by this step.

[infogulch]

Awesome! Don't bother with write access or anything, I'll fork it and make a pull request.

[IsNull]

Ah I forgot about the nice pull request feature Even better this way.

[IsNull]

Update 1.1 Usng now the namespace trick by maul.esel, all classes are now nested in DBA.

[tinku99]

Update 1.1 Usng now the namespace trick by maul.esel, all classes are now nested in DBA.

Thanks for this nice library.

while you're refactoring, consider using infogulch's trick to wrap dll libraries:
<!-- m -->https://github.com/i... ... enGL.ahk_l<!-- m -->
I used it in my zmq class.

__call(func, args*) {
        types := this[func].arg_types
            loop % types.maxindex() 
                args.insert((A_Index<<1)-1, types[A_Index])
            args.insert("cdecl " this[func].returntype)
            ; msgbox % tostring(args)
        return DllCall("libzmq\" func, args*)      
    }                                  
static zmq_msg_init := {arg_types: ["Ptr"], returntype : "int"}
static zmq_msg_init_size := {arg_types: ["Ptr", "uint"], returntype : "int"}

Also, could you include tod wolffe's UDF callbacks implementations for sqlite ?
<!-- m -->http://www.autohotke... ... e callback<!-- m -->

[infogulch]

So are you going to push these changes to github?

[tinku99]

I have not used SQLite from ahk myself yet. When I do, I will put it on github.