Re: [fpc-devel] TClientDataset (was: Dnamic packages support)
On Sun, 4 Nov 2007, Joost van der Sluis wrote: Op zondag 04-11-2007 om 00:34 uur [tijdzone +0100], schreef Michael Van Canneyt: On Sat, 3 Nov 2007, Joost van der Sluis wrote: Op zaterdag 03-11-2007 om 19:57 uur [tijdzone +0100], schreef Michael Van Canneyt: Packages and the missing TClientDataset are the only 2 remaining things stopping me from using FPC/Lazarus for my daytime job. All else is covered or can be covered with a minimal amount of work. You'll have to explain the TClientDataset to me. Do you need a symantical identical equivalent of TClientDataset? I need all features offered by TClientDataset: - 3-tier database handling, TProvider and all. - Local filtering - Local sorting/indexing - Locate() - Maintained Aggregates - Load/Save to file (briefcase model) And all features are critical; We have about 3200 instances in 1 application, almost all of them using all of the features mentioned, maybe with exception of the aggregates. Or do you only miss some features in sqldb? SQLDB will be good for our server tier, so I can drop the IBX. But it's not suitable for the client layer. As I see it, TClientDataset should be built on top of TBufDataset. Local filtering is available as fas as I know (or did you put it in TSQLQuery ?), and the indexing probably also can somehow be managed. The locate can be done with a filter. The maintained aggregates would need to be implemented from scratch, as well as the packet handling and file handling... Local filtering is in TBufDataset, locate also. The packet-handling is also there? So you can create a delta packet, it can be sent/applied/whatever, and you can integrate whatever changes were incorporated after the delta was applied ? I must have missed that ? Only no file-handling. But that's more because I didn't find it urgent enough to implement. It should be very easy. And there are no local indexes. The local indexes are one of THE most important things. The file handling is relatively easy, but should be designed well so it can handle various formats. Bu I know where to work on now. But there's also a design-issue. You talked about a TProvider. But as TBufdataset is setup know, you don't need any. For every kind of connection between TBufDataset and the ouside world, you'll have to use another descendent of TBufDataset. TProvider is needed to 1. Supply initial data. 2. Apply the deltas and send back reconciling data. So we can add a TProviderDataset or something, that can connect to data on an application-server. Is this ok to you? That way you always heve to re-create your descendent of TBufDataset for every connection? Hm. I'm not sure I understand this ? Or do you like the TClientDataset model better? So that you can connect it to any TProvider you want - to get access to some data? This is essential; Without this it is useless to me. You're right that we could make a TClientDataset which inherits from TBufDataset. But that kind of defeats the purpose of TBufDataset. Nono. You should split out functionalities: The TBufDataset should handle what it handles now, plus the local indexes and saving to file. In short: a complete in-memory dataset. It doesn't care where the actual data comes from; This is the job of a descendent. (TSQLQuery, TClientDataset) What TClientDataset adds to this is the ability to work with a TProvider: - Get records from a remote source (IAppProvider interface). - Send and Apply delta, integrate result back in buffer. Because if you do so, it would also be better to base TSQLQuery on TDataset directly. Or else you're double-buffering your data when you connect a TSQLQuery (TBufDataset) with a TProvider to a TClientDataset (another TBufDataset). You'll always have double buffering. Don't forget that TSQLQuery and TProvider are on the application server tier, and TClientDataset is on the client tier. The client tier doesn't have direct access to the database so TSQLQuery would be useless. That's why a 'unidirectional' property in TSQLQuery/TBufDataset is needed: in that case, only 2 buffers are needed: one for the current record and one for edit/update/filter. Makes a HUGE difference on the server. IBX implemented it especially for that. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TClientDataset (was: Dnamic packages support)
Op maandag 05-11-2007 om 10:44 uur [tijdzone +0100], schreef Michael Van Canneyt: On Sun, 4 Nov 2007, Joost van der Sluis wrote: Op zondag 04-11-2007 om 00:34 uur [tijdzone +0100], schreef Michael Van Canneyt: On Sat, 3 Nov 2007, Joost van der Sluis wrote: Op zaterdag 03-11-2007 om 19:57 uur [tijdzone +0100], schreef Michael Van Canneyt: Packages and the missing TClientDataset are the only 2 remaining things stopping me from using FPC/Lazarus for my daytime job. All else is covered or can be covered with a minimal amount of work. You'll have to explain the TClientDataset to me. Do you need a symantical identical equivalent of TClientDataset? I need all features offered by TClientDataset: - 3-tier database handling, TProvider and all. - Local filtering - Local sorting/indexing - Locate() - Maintained Aggregates - Load/Save to file (briefcase model) And all features are critical; We have about 3200 instances in 1 application, almost all of them using all of the features mentioned, maybe with exception of the aggregates. Or do you only miss some features in sqldb? SQLDB will be good for our server tier, so I can drop the IBX. But it's not suitable for the client layer. As I see it, TClientDataset should be built on top of TBufDataset. Local filtering is available as fas as I know (or did you put it in TSQLQuery ?), and the indexing probably also can somehow be managed. The locate can be done with a filter. The maintained aggregates would need to be implemented from scratch, as well as the packet handling and file handling... Local filtering is in TBufDataset, locate also. The packet-handling is also there? So you can create a delta packet, it can be sent/applied/whatever, and you can integrate whatever changes were incorporated after the delta was applied ? I must have missed that ? Yes. But you can only apply the 'delta-packet'. Or cancel it, offcourse (ie: remove it). But that's because saving to disk and sending to another TDataser or over the network isn't implemented at all. Only no file-handling. But that's more because I didn't find it urgent enough to implement. It should be very easy. And there are no local indexes. The local indexes are one of THE most important things. The file handling is relatively easy, but should be designed well so it can handle various formats. Bu I know where to work on now. But there's also a design-issue. You talked about a TProvider. But as TBufdataset is setup know, you don't need any. For every kind of connection between TBufDataset and the ouside world, you'll have to use another descendent of TBufDataset. TProvider is needed to 1. Supply initial data. 2. Apply the deltas and send back reconciling data. You don't need a TProvider for that. Take for example sqldb: TSQLQuery does nothing more (or less) then a TProvider would do. TBufDataset does the rest. (btw: TSQLQuert doesn't send back reconciling data, although TBufdataset can handle it) So we can add a TProviderDataset or something, that can connect to data on an application-server. Is this ok to you? That way you always heve to re-create your descendent of TBufDataset for every connection? Hm. I'm not sure I understand this ? Read the example above. See TSQLCustomQuery as the provider, TBufDataset as the TClientDataset. Or do you like the TClientDataset model better? So that you can connect it to any TProvider you want - to get access to some data? This is essential; Without this it is useless to me. I need to know if you can also use the model above. You're right that we could make a TClientDataset which inherits from TBufDataset. But that kind of defeats the purpose of TBufDataset. Nono. You should split out functionalities: The TBufDataset should handle what it handles now, plus the local indexes and saving to file. In short: a complete in-memory dataset. It doesn't care where the actual data comes from; This is the job of a descendent. (TSQLQuery, TClientDataset) What TClientDataset adds to this is the ability to work with a TProvider: - Get records from a remote source (IAppProvider interface). - Send and Apply delta, integrate result back in buffer. TBufDataset can already do this. A descendent has to: Override Fetch, LoadField, LoadBlobintoBuffer and ApplyrecUpdate. (integrating the results in the buffer is done by TBufDataset, just as TClientDataset does) So TClientDataset could override these functions simply in such a way that they call the same functions, but then form an external provider. ie: function TClientDataset.Fetch : boolean; begin Result := AProvider.Fetch; end; And all the like... If you really need compatibility with the IAppProvider interface (why?) then there's more work to do. But that was what I meant with my first question. Do you
Re: [fpc-devel] TClientDataset (was: Dnamic packages support)
On Mon, 5 Nov 2007, Joost van der Sluis wrote: Op maandag 05-11-2007 om 10:44 uur [tijdzone +0100], schreef Michael Van Canneyt: On Sun, 4 Nov 2007, Joost van der Sluis wrote: Op zondag 04-11-2007 om 00:34 uur [tijdzone +0100], schreef Michael Van Canneyt: On Sat, 3 Nov 2007, Joost van der Sluis wrote: Op zaterdag 03-11-2007 om 19:57 uur [tijdzone +0100], schreef Michael Van Canneyt: Packages and the missing TClientDataset are the only 2 remaining things stopping me from using FPC/Lazarus for my daytime job. All else is covered or can be covered with a minimal amount of work. You'll have to explain the TClientDataset to me. Do you need a symantical identical equivalent of TClientDataset? I need all features offered by TClientDataset: - 3-tier database handling, TProvider and all. - Local filtering - Local sorting/indexing - Locate() - Maintained Aggregates - Load/Save to file (briefcase model) And all features are critical; We have about 3200 instances in 1 application, almost all of them using all of the features mentioned, maybe with exception of the aggregates. Or do you only miss some features in sqldb? SQLDB will be good for our server tier, so I can drop the IBX. But it's not suitable for the client layer. As I see it, TClientDataset should be built on top of TBufDataset. Local filtering is available as fas as I know (or did you put it in TSQLQuery ?), and the indexing probably also can somehow be managed. The locate can be done with a filter. The maintained aggregates would need to be implemented from scratch, as well as the packet handling and file handling... Local filtering is in TBufDataset, locate also. The packet-handling is also there? So you can create a delta packet, it can be sent/applied/whatever, and you can integrate whatever changes were incorporated after the delta was applied ? I must have missed that ? Yes. But you can only apply the 'delta-packet'. Or cancel it, offcourse (ie: remove it). But that's because saving to disk and sending to another TDataser or over the network isn't implemented at all. Aha. So we're partly there. TProvider is needed to 1. Supply initial data. 2. Apply the deltas and send back reconciling data. You don't need a TProvider for that. Take for example sqldb: TSQLQuery does nothing more (or less) then a TProvider would do. TBufDataset does the rest. (btw: TSQLQuert doesn't send back reconciling data, although TBufdataset can handle it) I understand all this, but the idea of TProvider is that the source of the data is opaque to the TClientDataset. So we can add a TProviderDataset or something, that can connect to data on an application-server. Is this ok to you? That way you always heve to re-create your descendent of TBufDataset for every connection? Hm. I'm not sure I understand this ? Read the example above. See TSQLCustomQuery as the provider, TBufDataset as the TClientDataset. Or do you like the TClientDataset model better? So that you can connect it to any TProvider you want - to get access to some data? This is essential; Without this it is useless to me. I need to know if you can also use the model above. If I understand your proposal correct, the answer is no. Which doesn't mean your proposal has no worth by itself, I think it does. You're right that we could make a TClientDataset which inherits from TBufDataset. But that kind of defeats the purpose of TBufDataset. Nono. You should split out functionalities: The TBufDataset should handle what it handles now, plus the local indexes and saving to file. In short: a complete in-memory dataset. It doesn't care where the actual data comes from; This is the job of a descendent. (TSQLQuery, TClientDataset) What TClientDataset adds to this is the ability to work with a TProvider: - Get records from a remote source (IAppProvider interface). - Send and Apply delta, integrate result back in buffer. TBufDataset can already do this. A descendent has to: Override Fetch, LoadField, LoadBlobintoBuffer and ApplyrecUpdate. (integrating the results in the buffer is done by TBufDataset, just as TClientDataset does) So TClientDataset could override these functions simply in such a way that they call the same functions, but then form an external provider. ie: function TClientDataset.Fetch : boolean; begin Result := AProvider.Fetch; end; And all the like... If you really need compatibility with the IAppProvider interface (why?) Why ? Because we make use of it in 3200 places, and recoding this is not an option :-) then there's more work to do. But that was what I meant with my first question. Do you need the functionality ot TClientDataset, or a symantical equivalent? I
Re: [fpc-devel] TClientDataset (was: Dnamic packages support)
From: Michael Van Canneyt [EMAIL PROTECTED] We could try to compile Borlands' VCL code with FPC, of course, but then there is the problem that the midas library is a black box, available only for windows i386, which kind of defeats the purpose of the whole exercise.. There is open source midas.dll implementation called HyperBase. http://www.vglib.com/link-4.html It can be made compilable by FPC to different platforms... Yury. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TClientDataset (was: Dnamic packages support)
On Mon, 5 Nov 2007, Yury Sidorov wrote: From: Michael Van Canneyt [EMAIL PROTECTED] We could try to compile Borlands' VCL code with FPC, of course, but then there is the problem that the midas library is a black box, available only for windows i386, which kind of defeats the purpose of the whole exercise.. There is open source midas.dll implementation called HyperBase. http://www.vglib.com/link-4.html It can be made compilable by FPC to different platforms... Yes, I have it since a very long time :-) But it contains bugs :/ But if there is no alternative then that would be an option. Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TClientDataset (was: Dnamic packages support)
Op maandag 05-11-2007 om 12:37 uur [tijdzone +0100], schreef Michael Van Canneyt: On Mon, 5 Nov 2007, Joost van der Sluis wrote: Op maandag 05-11-2007 om 10:44 uur [tijdzone +0100], schreef Michael Van Canneyt: On Sun, 4 Nov 2007, Joost van der Sluis wrote: Op zondag 04-11-2007 om 00:34 uur [tijdzone +0100], schreef Michael Van Canneyt: On Sat, 3 Nov 2007, Joost van der Sluis wrote: Op zaterdag 03-11-2007 om 19:57 uur [tijdzone +0100], schreef Michael Van Canneyt: Packages and the missing TClientDataset are the only 2 remaining things stopping me from using FPC/Lazarus for my daytime job. All else is covered or can be covered with a minimal amount of work. You'll have to explain the TClientDataset to me. Do you need a symantical identical equivalent of TClientDataset? I need all features offered by TClientDataset: - 3-tier database handling, TProvider and all. - Local filtering - Local sorting/indexing - Locate() - Maintained Aggregates - Load/Save to file (briefcase model) And all features are critical; We have about 3200 instances in 1 application, almost all of them using all of the features mentioned, maybe with exception of the aggregates. Or do you only miss some features in sqldb? SQLDB will be good for our server tier, so I can drop the IBX. But it's not suitable for the client layer. As I see it, TClientDataset should be built on top of TBufDataset. Local filtering is available as fas as I know (or did you put it in TSQLQuery ?), and the indexing probably also can somehow be managed. The locate can be done with a filter. The maintained aggregates would need to be implemented from scratch, as well as the packet handling and file handling... Local filtering is in TBufDataset, locate also. The packet-handling is also there? So you can create a delta packet, it can be sent/applied/whatever, and you can integrate whatever changes were incorporated after the delta was applied ? I must have missed that ? Yes. But you can only apply the 'delta-packet'. Or cancel it, offcourse (ie: remove it). But that's because saving to disk and sending to another TDataser or over the network isn't implemented at all. Aha. So we're partly there. TProvider is needed to 1. Supply initial data. 2. Apply the deltas and send back reconciling data. You don't need a TProvider for that. Take for example sqldb: TSQLQuery does nothing more (or less) then a TProvider would do. TBufDataset does the rest. (btw: TSQLQuert doesn't send back reconciling data, although TBufdataset can handle it) I understand all this, but the idea of TProvider is that the source of the data is opaque to the TClientDataset. So we can add a TProviderDataset or something, that can connect to data on an application-server. Is this ok to you? That way you always heve to re-create your descendent of TBufDataset for every connection? Hm. I'm not sure I understand this ? Read the example above. See TSQLCustomQuery as the provider, TBufDataset as the TClientDataset. Or do you like the TClientDataset model better? So that you can connect it to any TProvider you want - to get access to some data? This is essential; Without this it is useless to me. I need to know if you can also use the model above. If I understand your proposal correct, the answer is no. Which doesn't mean your proposal has no worth by itself, I think it does. You're right that we could make a TClientDataset which inherits from TBufDataset. But that kind of defeats the purpose of TBufDataset. Nono. You should split out functionalities: The TBufDataset should handle what it handles now, plus the local indexes and saving to file. In short: a complete in-memory dataset. It doesn't care where the actual data comes from; This is the job of a descendent. (TSQLQuery, TClientDataset) What TClientDataset adds to this is the ability to work with a TProvider: - Get records from a remote source (IAppProvider interface). - Send and Apply delta, integrate result back in buffer. TBufDataset can already do this. A descendent has to: Override Fetch, LoadField, LoadBlobintoBuffer and ApplyrecUpdate. (integrating the results in the buffer is done by TBufDataset, just as TClientDataset does) So TClientDataset could override these functions simply in such a way that they call the same functions, but then form an external provider. ie: function TClientDataset.Fetch : boolean; begin Result := AProvider.Fetch; end; And all the like... If you really need compatibility with the IAppProvider interface (why?) Why ? Because we
Re: [fpc-devel] TClientDataset (was: Dnamic packages support)
On Mon, 5 Nov 2007, Joost van der Sluis wrote: Why ? Because we make use of it in 3200 places, and recoding this is not an option :-) Ok, then there's the question: Do we want to provide the ability to use existing DB-code with fpc? It's a serious question, because if decide to do so, that will cost resources which could be otherwise used for something else. (Implementing a better db-model? Is the Delphi-model perfect?) I think that the DB model of Delphi is very OK, but can use some extensions. for instance TBufDataset can have a property Records[I : Integer] which could give direct indexed access to all records in the dataset (as, I understood, .NET does). This need not conflict with the current implementation. What concerns the possibilities of N-Tier, I have the same opinion. The ideas of Borland are OK, but the implementation can use some improvements. DataAbstract of Remobjects springs to mind. (although that one as well can use some improvements...) If I would start from zero, I would not have problems with setting up the whole thing to something like you describe. The main problem is that there is almost 10 years of code which should work as-is, as much as possible. Since we heavily rely on almost all aspects of TClientDataset/TProvider stuff, that means we need it almost 100% equivalently... We could try to compile Borlands' VCL code with FPC, of course, but then there is the problem that the midas library is a black box, available only for windows i386, which kind of defeats the purpose of the whole exercise.. I think I understand your point of view now. At first I thought that TBufDataset wouldn't be needed if we make a TClientDataset. But if you want to use a property to switch unidirectional on and off, it makes sense. Great, understanding is already half the path :-) What concerns the exact details of implementation, well, there we'll have to see. I can live with a small change in API (getting rid of variants, for one), as long as the global mechanism and idea is there. Maybe we should get together once, and sit around the drawing board... Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TClientDataset (was: Dnamic packages support)
On 05/11/2007, Michael Van Canneyt [EMAIL PROTECTED] wrote: There is open source midas.dll implementation called HyperBase. http://www.vglib.com/link-4.html It can be made compilable by FPC to different platforms... Yes, I have it since a very long time :-) But it contains bugs :/ But if there is no alternative then that would be an option. I don't understand the internals of Midas, but did help maintain a product that used 3-tier (with midas application server). Could one implement a application server using SOAP instead? I remember reading an article (I think his name was Brian Long or Dr.Bob) where he created a standalone (very simple) webserver application using Indy's server components and used that as the application server. Then connected with application clients via SOAP+HTTP. Is something like this possible with FPC? I guess the first question is, do we have a webserver component for FPC? Secondly, does FPC support SOAP? What actually happens inside the midas.dll? Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TClientDataset (was: Dnamic packages support)
On Mon, 5 Nov 2007, Graeme Geldenhuys wrote: On 05/11/2007, Michael Van Canneyt [EMAIL PROTECTED] wrote: There is open source midas.dll implementation called HyperBase. http://www.vglib.com/link-4.html It can be made compilable by FPC to different platforms... Yes, I have it since a very long time :-) But it contains bugs :/ But if there is no alternative then that would be an option. I don't understand the internals of Midas, but did help maintain a product that used 3-tier (with midas application server). Could one implement a application server using SOAP instead? Yes. Such a server comes even standard with Delphi. I remember reading an article (I think his name was Brian Long or Dr.Bob) where he created a standalone (very simple) webserver application using Indy's server components and used that as the application server. Then connected with application clients via SOAP+HTTP. Is something like this possible with FPC? I guess the first question is, do we have a webserver component for FPC? Secondly, does FPC support SOAP? Yes on both accounts. What actually happens inside the midas.dll? It maintains an in-memory data packet, and is able to do - local filtering - local indexing - locating data - Maintained aggregates - Save/load from file - Create and merge deltas. TClientDataset is just a wrapper around this. TBufDataset in FPC has already many of these things, but not yet all. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TClientDataset (was: Dnamic packages support)
On 05/11/2007, Michael Van Canneyt [EMAIL PROTECTED] wrote: Is something like this possible with FPC? I guess the first question is, do we have a webserver component for FPC? Secondly, does FPC support SOAP? Yes on both accounts. Excellent, something new to experiment with. Where could I find that webserver component? ...and thanks for the info on midas! I'm thinking of implementing some type of application server that sits on the same server (or even elsewhere) as my CGI apps. Currently my CGI apps have to grab the web variables, open a db connection, read the data, process it into a HTML page and close the DB connection. Opening and Closing DB connections tend to be slow, so if some application server can keep the connection open and just return the requested data to the CGI app, it should speed things up (I think). PS: I have no idea how you do performance/speed tests with CGI apps! This idea is all in theory. ;-) Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TClientDataset (was: Dnamic packages support)
On Mon, 5 Nov 2007, Graeme Geldenhuys wrote: On 05/11/2007, Michael Van Canneyt [EMAIL PROTECTED] wrote: Is something like this possible with FPC? I guess the first question is, do we have a webserver component for FPC? Secondly, does FPC support SOAP? Yes on both accounts. Excellent, something new to experiment with. Where could I find that webserver component? - Webserver component is in Indy or in LNet (maybe even synapse) - Soap server in WST, (pascal webservices toolkit) it's on Lazarus CCR. ...and thanks for the info on midas! You're welcome. I'm thinking of implementing some type of application server that sits on the same server (or even elsewhere) as my CGI apps. Currently my CGI apps have to grab the web variables, open a db connection, read the data, process it into a HTML page and close the DB connection. Opening and Closing DB connections tend to be slow, so if some application server can keep the connection open and just return the requested data to the CGI app, it should speed things up (I think). It should, yes. Better yet is to write an Apache module. A breeze with FPC these days... PS: I have no idea how you do performance/speed tests with CGI apps! This idea is all in theory. ;-) Take a couple of PC's and fire wget a 1000 times on your CGI app. Better yet, use some of the FPC components (lnet, synapse) to do it in a tight loop. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TClientDataset (was: Dnamic packages support)
On 05/11/2007, Michael Van Canneyt [EMAIL PROTECTED] wrote: It should, yes. Better yet is to write an Apache module. A breeze with FPC these days... I know nothing about Apache modules, but from you comment, I guess I need to look into it. * Can they hold a DB connection open as well? * Are they specific to a Apache version? We are going to deploy on Apache 2.x but the minor version numbers might not always be the same. Also deployment will be on Linux and Windows servers. Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TClientDataset (was: Dnamic packages support)
On Tue, 6 Nov 2007, Graeme Geldenhuys wrote: On 05/11/2007, Michael Van Canneyt [EMAIL PROTECTED] wrote: It should, yes. Better yet is to write an Apache module. A breeze with FPC these days... I know nothing about Apache modules, but from you comment, I guess I need to look into it. * Can they hold a DB connection open as well? Yes, of course. * Are they specific to a Apache version? We are going to deploy on Apache 2.x but the minor version numbers might not always be the same. Also deployment will be on Linux and Windows servers. 2.0 differs from 2.2, but your code will not depend on it. It's a simple recompile, you could even create a single module to suit the 2 versions. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TClientDataset (was: Dnamic packages support)
Op zondag 04-11-2007 om 00:34 uur [tijdzone +0100], schreef Michael Van Canneyt: On Sat, 3 Nov 2007, Joost van der Sluis wrote: Op zaterdag 03-11-2007 om 19:57 uur [tijdzone +0100], schreef Michael Van Canneyt: Packages and the missing TClientDataset are the only 2 remaining things stopping me from using FPC/Lazarus for my daytime job. All else is covered or can be covered with a minimal amount of work. You'll have to explain the TClientDataset to me. Do you need a symantical identical equivalent of TClientDataset? I need all features offered by TClientDataset: - 3-tier database handling, TProvider and all. - Local filtering - Local sorting/indexing - Locate() - Maintained Aggregates - Load/Save to file (briefcase model) And all features are critical; We have about 3200 instances in 1 application, almost all of them using all of the features mentioned, maybe with exception of the aggregates. Or do you only miss some features in sqldb? SQLDB will be good for our server tier, so I can drop the IBX. But it's not suitable for the client layer. As I see it, TClientDataset should be built on top of TBufDataset. Local filtering is available as fas as I know (or did you put it in TSQLQuery ?), and the indexing probably also can somehow be managed. The locate can be done with a filter. The maintained aggregates would need to be implemented from scratch, as well as the packet handling and file handling... Local filtering is in TBufDataset, locate also. The packet-handling is also there? Only no file-handling. But that's more because I didn't find it urgent enough to implement. It should be very easy. And there are no local indexes. Bu I know where to work on now. But there's also a design-issue. You talked about a TProvider. But as TBufdataset is setup know, you don't need any. For every kind of connection between TBufDataset and the ouside world, you'll have to use another descendent of TBufDataset. So we can add a TProviderDataset or something, that can connect to data on an application-server. Is this ok to you? That way you always heve to re-create your descendent of TBufDataset for every connection? Or do you like the TClientDataset model better? So that you can connect it to any TProvider you want - to get access to some data? You're right that we could make a TClientDataset which inherits from TBufDataset. But that kind of defeats the purpose of TBufDataset. Because if you do so, it would also be better to base TSQLQuery on TDataset directly. Or else you're double-buffering your data when you connect a TSQLQuery (TBufDataset) with a TProvider to a TClientDataset (another TBufDataset). Joost ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] TClientDataset (was: Dnamic packages support)
On Sat, 3 Nov 2007, Joost van der Sluis wrote: Op zaterdag 03-11-2007 om 19:57 uur [tijdzone +0100], schreef Michael Van Canneyt: Packages and the missing TClientDataset are the only 2 remaining things stopping me from using FPC/Lazarus for my daytime job. All else is covered or can be covered with a minimal amount of work. You'll have to explain the TClientDataset to me. Do you need a symantical identical equivalent of TClientDataset? I need all features offered by TClientDataset: - 3-tier database handling, TProvider and all. - Local filtering - Local sorting/indexing - Locate() - Maintained Aggregates - Load/Save to file (briefcase model) And all features are critical; We have about 3200 instances in 1 application, almost all of them using all of the features mentioned, maybe with exception of the aggregates. Or do you only miss some features in sqldb? SQLDB will be good for our server tier, so I can drop the IBX. But it's not suitable for the client layer. As I see it, TClientDataset should be built on top of TBufDataset. Local filtering is available as fas as I know (or did you put it in TSQLQuery ?), and the indexing probably also can somehow be managed. The locate can be done with a filter. The maintained aggregates would need to be implemented from scratch, as well as the packet handling and file handling... Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel