Sorry about the formatting I had to drag it out to vim and do it.
Darren Duncan wrote: > Are you saying that one should be able to write PDBI drivers entirely > in PASM or IMCC and they would actually be able to talk to the various > database products, or do PDBI drivers actually need to be written in > C?
Yes, we are able to call out to shared libs using the NCI which is a very handy feature. It also makes us less platform dependant. I doubt we
will be writing any of the code in PASM because IMC is much easier to use.
> I would have expected that they need to be written in C, since the > native database product drivers they talk to are only C-compatible; > however, then the drivers *would* have to be compiled on each > platform. But if they are entirely PASM or IMCC, then what features > does Parrot provide that would magically talk to the native C > libraries for each database product?
Native Call Interface (NCI)
> 2. Is PDBI mainly meant to be a clone of the tried-and-true DBI for > Perl 5, with a virtually identical feature set aside from the fact > that it is meant to work with any language running on Parrot? Or do > you truly desire to have some serious innovation in features and > design over the "old world" framework, which would put a lot more > power in the hands of users than they ever had before?
If we manage to get a clone with everything working as well as it is
today I would be fairly happy. As for extra features being added to the DBI I would first try the DBI dev mailing list. I am sure they are open to sugestions for new features that would enhance the DBI. Tim has already asked people if they have any feature requests etc that they would like to see in version 2 (If I am not mistaken). If it cannot be added at that point for whatever reason and everyone agrees that it would be a great feature then bring it up here where it might become a possibility or at least it can be investigated.
If you have a radical idea then come up with a proposal and I am sure that there are enough people on here to discuss it. As far as completely changing the DBI is concerned I would be all ears to anyone who can come up with a better framework given the complexity of the task.
> And don't get me wrong here, I'm not discounting that multi-language > is a huge step forward by itself, along with the significant savings > of labour that would have been spent making a separate clone for each > language. It's just that, looking on an individual language basis, > what I have seen so far implies that users will get the same features > as before and not more or different.
This has yet to be seen. One of the reasons for this mailing list is to see what people would like added where possible.
> 3. Do you have any plans to use named bind variables (eg ":foo") > rather than positional ones, like the current '?' design? I see a > switch to named to be a relatively simple and yet very powerful > improvement. For one thing, often the same value is used multiple > times in a SQL statement; for another, it is rather tedious to keep > track of long lists of '?' and keep them in sync between their > appearances in the SQL passed to prepare() and the variable list in > execute().
Don't Know.
> My point is that, depending on what your goals are with PDBI, I am > hoping that you can utilize the work I did with Rosetta in order to > speed development of a powerful PDBI. I know that in the medium to > long run I wanted to have a support/developer network in my project as > DBI does, but if we can combine efforts, then developers can work once > and further the common good rather than having to choose. In this > way, my work can help the community the most.
> On the other hand, if it is not among your goals to permit > applications to use identical SQL for all database operations no > matter which database product they talk to, then I would alternately > like to keep my extra goals as a separate layer from the PDBI core, > and work with you so that the two are desiged to interact efficiently. > Likewise, if you have no plans to let applications written in compiled > languages use the features of this database library.
Can you be more spefic about what you mean by "identical SQL". Are you
suggesting that we try and follow a standard like SQL/92 or SQL3. To quote CJ Date, "products typically support what might be called a 'superset of a subset' of SQL/92". Several of the larger database have been trying, some harder than others and each and every one unsuccessfully, to adhere to the SQL/92 standard and the SQL3 standard is much bigger. It would be great if we where all able to use the same SQL for all our operations no matter what the database but this is no easy task. How would you propose we should approach such a task bearing in mind that the database world all use and understand what they need of SQL and would not take too kindly to changing to something that looked even remotely different.
On the other hand there is also ODBC.
Harry
