Re: [fpc-pascal] Database Metadata proposal
Hi Daniel,
If I understand correctly, when you will use new GetObjectNames then you
must itterate throught returned collection to obtain schema names +
object names (f.e. table names).
IMO very similar result you can get also with existing implementation,
when you use:
with SQLQuery1 do begin
SetSchemaInfo(stTables); // here you can set type of schema query like
stTables, stColumns, stProcedures, stSchemata etc.
Open; // here is opened dataset with requested schema query
while not Eof do begin
// here you can use FieldByName('SCHAME_NAME').AsString ,
FieldByName('TABLE_NAME').AsString, etc.
Next;
end;
end;
-Laco.
An Issue was created with the patch:
http://bugs.freepascal.org/view.php?id=26254
On Sun, Jun 1, 2014 at 11:28 AM, Daniel Gaspary dgasp...@gmail.com wrote:
I see no problem. It was just a wrong impression that I had about
TCollectionItem.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] EpikTimer v1.0.1 released
On 05/28/2014 06:09 PM, Henry Vermaak wrote: an ifdef to call QueryPerformanceCounter/()clock_gettime() based on OS. Things like this is why I'd rather use dVSO. Calling the vDSO will certainly make things faster. For me, the point is, that with vDSO, the Linux infrastructure will handle the dirty stuff that is involved with such low level greatly arch depending things. It is supposed to work out of the box, even if for certain archs no support from the hardware is available and provide the best possible support by the Kernel software. For C programmers, this is automatically in place, as libC and the Kernel are done appropriately. fpc (supposedly for good reasons) is determined to reduce libC dependance as much as possible. Hence the rtl needs to provide arch dependent low level stuff internally. As it is provided directly by the Linux Kernel, vDSO is a way to take advantage of Kernel provided arch-independence without using libC. -Michael ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] EpikTimer v1.0.1 released
On 05/28/2014 05:41 PM, Marco van de Voort wrote: . But that means you need to use OS timing functions, and not ASM. Meaning either syscalls or vDSO. As in Linux syscalls do a usermode-Kernelmode-usermode switch, they introduce a huger overhead. In Windows I suppose syscalls usually are not done directly by the rtl, but functions calls to a Kernel dll are done, so that that Windows.provide dll might decide to stay in usermode if possible. -Michael ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] EpikTimer v1.0.1 released
On 05/28/2014 06:03 PM, Henry Vermaak wrote: Blindly making assumptions about TSC stability can get you into trouble. Microsoft advises against this, too: http://msdn.microsoft.com/en-gb/library/windows/desktop/ee417693%28v=vs.85%29.aspx As my Target is Linux, this does not help with the implementation. But the warning not to use TSC holds, anyway ! -Michael ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] EpikTimer v1.0.1 released
On 05/29/2014 01:17 AM, Graeme Geldenhuys wrote: Then fork it on Github and start publishing your changes. I'll gladly review the suggestions and merge it what works. OK. (Of course only after I did as much testing as possible - in fact I can't do by far enough.) This discussion shows that the arch depending stuff in the library/packet really should be part of the rtl. There is not much chance to finally provide a decent / manageable / stable arch independent functionality to the users. -Michael ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] EpikTimer v1.0.1 released
Am 02.06.2014 10:38 schrieb Michael Schnell mschn...@lumino.de: In Windows I suppose syscalls usually are not done directly by the rtl, but functions calls to a Kernel dll are done, so that that Windows.provide dll might decide to stay in usermode if possible. On Windows the QueryPerfomanceCounter/Frequency calls always do a syscall, because the corresponding code is implemented in the HAL which is only accessible from kernel mode. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] EpikTimer v1.0.1 released
Am 02.06.2014 10:38 schrieb Michael Schnell mschn...@lumino.de: In Windows I suppose syscalls usually are not done directly by the rtl, but functions calls to a Kernel dll are done, so that that Windows.provide dll might decide to stay in usermode if possible. Addendum: yes, the RTL calls the core DLLs of the Win32 subsystem like kernel32.dll, but they are just that: the core DLLs of the Win32 subsystem. They don't implement any core OS functionality like hardware/device management, because that is done by the NT kernel below it which is called by the Win32 DLLs if needed using the ntdll.dll which acts as a gateway to the kernel (some calls will do a Syscall then, for example hardware related functions, while others like functions to handle list structures will stay in the current mode). That's basically a remnant of the microkernel nature of the NT OS. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] EpikTimer v1.0.1 released
On 06/02/2014 11:06 AM, Sven Barth wrote: Addendum: yes, the RTL calls the core DLLs of the Win32 subsystem like kernel32.dll, but they are just that: the core DLLs of the Win32 subsystem. They don't implement any core OS functionality like hardware/device management, because that is done by the NT kernel below it which is called by the Win32 DLLs if needed using the ntdll.dll which acts as a gateway to the kernel (some calls will do a Syscall then, for example hardware related functions, while others like functions to handle list structures will stay in the current mode). That's basically a remnant of the microkernel nature of the NT OS. This is rather similar to what I assumed. Hence, if (as your other post suggests) that Kernel dll switches to Kernel mode to access TSC in an X86 archs while this is not necessary, that is a fault of Windows' and not a fault of fpc's and hence we can't help it. As we found, blindly reading is not a good idea, so a really fast rtl function would need to detect the CPU sub-arch and act appropriately. I understand that this is close to impossible. -Michael ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] EpikTimer v1.0.1 released
In our previous episode, Michael Schnell said: On 05/28/2014 05:41 PM, Marco van de Voort wrote: . But that means you need to use OS timing functions, and not ASM. Meaning either syscalls or vDSO. As in Linux syscalls do a usermode-Kernelmode-usermode switch, they introduce a huger overhead. Maybe, but is that relevant? We were talking about precision, not speed. In Windows I suppose syscalls usually are not done directly by the rtl, No. Windows calls kernel32/user32, which then mostly calls nt.dll functions to do the actual syscalls afaik. And a lot more is userland on Windows. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] EpikTimer v1.0.1 released
On 06/02/2014 11:49 AM, Marco van de Voort wrote: Maybe, but is that relevant? We were talking about precision, not speed. I have been talking about overhead (speed) all the time. This is my intention to discuss the issue. Bus regarding time measurement of course speed and precision is highly related, so IMHO it's really decent to handle both aspects together. -Michael ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] EpikTimer v1.0.1 released
On 06/02/2014 11:49 AM, Marco van de Voort wrote: In Windows I suppose syscalls usually are not done directly by the rtl, No. Windows calls kernel32/user32, which then mostly calls nt.dll functions I feel free to translate this to: In Windows, the fpc rtl calls kernel32/user32, ... Which is _exactly_ what I said. -Michael ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Database Metadata proposal
On Mon, Jun 2, 2014 at 3:01 AM, LacaK la...@zoznam.sk wrote: IMO very similar result you can get also with existing implementation, when you use: Yes, this is the way GetDBInfo do, but it's not public, and never return schema. What I did was to copy and modify this method. I have sent a patch: http://bugs.freepascal.org/view.php?id=26254 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Database Metadata proposal
Daniel Gaspary wrote / napísal(a): On Mon, Jun 2, 2014 at 3:01 AM, LacaK la...@zoznam.sk wrote: IMO very similar result you can get also with existing implementation, when you use: Yes, this is the way GetDBInfo do, but it's not public, and never return schema. Code which I have attached uses only public methods and returns metadata dataset which has also schema_name column (for SQLConnection which support schemas. I have used public method SetSchemaInfo not GetDBInfo) What I did was to copy and modify this method. I have sent a patch: http://bugs.freepascal.org/view.php?id=26254 Yes I see it, but as I wrote your new method returns collection, which you must process, which is more or less what you can do with metadata dataset -Laco. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Database Metadata proposal
On Mon, 2 Jun 2014, LacaK wrote:
Daniel Gaspary wrote / napísal(a):
On Mon, Jun 2, 2014 at 3:01 AM, LacaK la...@zoznam.sk wrote:
IMO very similar result you can get also with existing implementation, when
you use:
Yes, this is the way GetDBInfo do, but it's not public, and never
return schema.
Code which I have attached uses only public methods and returns metadata
dataset which has also schema_name column
(for SQLConnection which support schemas. I have used public method
SetSchemaInfo not GetDBInfo)
What I did was to copy and modify this method.
I have sent a patch: http://bugs.freepascal.org/view.php?id=26254
Yes I see it, but as I wrote your new method returns collection, which you must process,
which is more or less what you can do with metadata dataset
While this is correct, the collection approach is much easier to use:
With the metadataset, you must know which fields exist and type them correctly:
FieldByName('XYZ').AsString
With collections, the IDE codetools will tell you what properties exist.
That is a order of magnitude more comfortable and less error prone.
Michael.___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Database Metadata proposal
On Mon, Jun 2, 2014 at 10:27 AM, LacaK la...@zoznam.sk wrote: (for SQLConnection which support schemas. I have used public method SetSchemaInfo not GetDBInfo) It's not public in SqlConnection, it's public in SqlQuery. Anyway, I don't see why avoid a dedicated method to do this instead of 3 steps which are not a clear. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Database Metadata proposal
On Mon, Jun 2, 2014 at 10:38 AM, Michael Van Canneyt
mich...@freepascal.org wrote:
While this is correct, the collection approach is much easier to use:
With the metadataset, you must know which fields exist and type them
correctly: FieldByName('XYZ').AsString
With collections, the IDE codetools will tell you what properties exist.
That is a order of magnitude more comfortable and less error prone.
Correct. And beyond the method, I have created the following const array:
TSchemaObjectNames: array[TSchemaType] of String = ('???', 'table_name',
'???', 'procedure_name', 'column_name', 'param_name',
'index_name', 'package_name', 'schema_name');
To avoid this need for retyping field names, over and over.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Database Metadata proposal
Michael Van Canneyt wrote / napísal(a):
On Mon, 2 Jun 2014, LacaK wrote:
Daniel Gaspary wrote / napísal(a):
On Mon, Jun 2, 2014 at 3:01 AM, LacaK la...@zoznam.sk wrote:
IMO very similar result you can get also with existing
implementation, when
you use:
Yes, this is the way GetDBInfo do, but it's not public, and never
return schema.
Code which I have attached uses only public methods and returns
metadata dataset which has also schema_name column
(for SQLConnection which support schemas. I have used public method
SetSchemaInfo not GetDBInfo)
What I did was to copy and modify this method.
I have sent a patch: http://bugs.freepascal.org/view.php?id=26254
Yes I see it, but as I wrote your new method returns collection,
which you must process, which is more or less what you can do with
metadata dataset
While this is correct, the collection approach is much easier to use:
With the metadataset, you must know which fields exist and type them
correctly: FieldByName('XYZ').AsString
With collections, the IDE codetools will tell you what properties exist.
That is a order of magnitude more comfortable and less error prone.
I still feel it a bit incompatible with existing interface.
If existing methods are not enough then we can return to already
discussed extension:
TSchemaOption = (soIncludeSchemaName, soSystemObjects, soQuoteNames);
TSchemaOptions = set of TSchemaOption;
and
TSQLConnection.GetTableNames(List: TStrings; SchemaName : String;
Options : TSchemaOptions);
or better new:
TSQLConnection.GetObjectNames(List: TStrings; SchemaType: TSchemaType;
Options : TSchemaOptions);
Which IMO fits better in existing frame.
-Laco.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
