Re: [fpc-devel] Changing transaction properties specific to IB when using IBConnection
Michael Van Canneyt wrote: ... I would propose to introduce a enumerated TSQLTransactionStyle =(tsConcurrent,tsReadCommit, etc.); Then add a TransactionStyle to TSQLTransaction; This must be mapped by the TSQLConnection when creating the handle. ... Indeed, this would be more elegant than my solution, but this would require finding some common functionality between various databases (Firebird, PostgreSQL, MySQL, and thinking about others in the future). I.e. something that would be both flexible and yet (at least relatively) portable to all TSQLConnection descendants. I'll look into this tomorrow. Although I may need some help about what transaction modes can be expressed in PostgreSQL and MySQL. I'll see tomorrow what I can do (and where I will need some help :). Michalis. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Changing transaction properties specific to IB when using IBConnection
Oh, and here's one additional patch to sqldb.pp that improves (ok, ok:
*corrects*) my previous patch. This way FTrans is not freed each time
transaction ends, so properties of FTrans like IsolationLevel are
preserved, e.g. code like
(Transaction.SQLHandle as TIBTrans).IsolationLevel := ilReadCommitted;
Transaction.StartTransaction;
...
Transaction.Commit;
Transaction.StartTransaction;
...
Transaction.Commit;
will create read committed transaction two times.
Michalis.
--- sqldb.pp.2 2005-03-18 13:46:20.640679760 +0100
+++ sqldb.pp 2005-03-18 13:50:49.156859096 +0100
@@ -112,6 +112,10 @@
TSQLTransaction = class (TDBTransaction)
private
+{ FTrans is created if needed in SQLHandle and StartTransaction,
+ and destroyed on Database change and in destructor.
+ The key is that assertion "Active => FTrans is for sure assigned"
+ is satisfied. }
FTrans : TSQLHandle;
FAction : TCommitRollbackAction;
protected
@@ -345,7 +349,6 @@
if (Database as tsqlconnection).commit(FTrans) then
begin
closeTrans;
- FreeAndNil(FTrans);
end;
end;
end;
@@ -364,7 +367,6 @@
if (Database as tsqlconnection).RollBack(FTrans) then
begin
CloseTrans;
- FreeAndNil(FTrans);
end;
end;
end;
@@ -402,6 +404,7 @@
destructor TSQLTransaction.Destroy;
begin
Rollback;
+ FreeAndNil(FTrans);
inherited Destroy;
end;
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Fix to IBConnection field names
Hi (This is completely unrelated to my previous patches to sqldb and ibconnection.) A simple correction that fixes a problem in IBConnection with field names: in TIBConnection.LoadField you look for field names using SQLDA^.SQLVar[x].AliasName, but in TIBConnection.AddFieldDefs you create fields with names using SQLDA^.SQLVar[x].SQLName. This is not good, as field's SQLName may be '' while it's AliasName may be 'COUNT' or something like that. In general, I think that you should use AliasNames everywhere. This also gives developer (the one who writes SQL statements) ability to change default field names using SQL (since you can explicitly say in select SQLs what AliasName should be used for some fields). So the fix is (I don't attach a patch, since this is too small..): change in TIBConnection.AddFieldDefs implementation "SQLName" to "AliasName". This way in whole IBConnection unit only AliasName of fields is used, never SQLName. Michalis. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Create installer for MacOSX
On 18 Mar 2005, at 15:10, Vincent Snijders wrote: Can you add the PackageMaker (script) file to cvs, just like is done forfpc.ist and fpc.spec? Not now, cvs.freepascal.org has been compromised. Note that you can use that (binary) file only with PackageMaker afaik, not with any command line tool. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Create installer for MacOSX
Jonas Maebe wrote: On 14 Mar 2005, at 22:40, Vincent Snijders wrote: I want to create a lazarus installer package for darwin (MacOSX). What tool should I use to create such a package? What tool does fpc use for packaging the compiler for MacOSX? I saw on sourceforge the MacOSX package is a .dmg file. How is that package created? make dmg in the fpc dir? No, manually. Creating a disk image is possible using command line tools, but creating an installer package isn't for some reason. You have to use /Developer/Applications/Utilities/PackageMaker for that. To create a disk image, either use Disk Utility or hdiutil create -imagekey zlib-level=9 -format UDZO -srcfolder Can you add the PackageMaker (script) file to cvs, just like is done for fpc.ist and fpc.spec? Regards, Vincent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Remember bug 3221
Please remember bug 3221 (memory leak by dynamic string as out parameter), the problem still exists on fpc 1.9.9. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] netdb, sockets, endianess
Since I'm working on networking support again, I cleaned up the FCL socket units (ssockets, fpsock, netdb, resolve) a bit. Mostly I did some order (endinaness) fixes, and removed the multitude of conversion routines (some of which quite faulty). I would like to call upon all users to retest/check netdb and help getting it in release-ready state. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] "Friend" classes?
Michael Van Canneyt wrote / napísal (a): On Wed, 16 Mar 2005, DrDiettrich wrote: Michael Van Canneyt wrote: type TFriendClass = class(TNotMyClass); This is a simple descendent. Yes and no. The only purpose of this declaration is to get access to the protected members of the class, not to extend the class in any way. Yes. This is OK, no ? 3) What alternatives could be used, so that not all class members must be made public, when they shall be used only in specific related units? ? Please explain. "protected" members of a class are for internal use only, not for public use. IMO it's against the spirit of visibility levels, when the protected and even private members of a class become accessible from outside the class, throughout the whole unit in which a class is defined. But sometimes multiple classes are designed for cooperation, where one class needs access to not normally accessible methods or properties of another class. When now the required methods are made public, they become available for abuse by everybody. With the above trick instead it's possible to gain access to the internals of a class, without making everything public. Such a backdoor does not prevent abuse, but as the (C++) term "friend" class suggests, it exists only for the sake of cooperation, and at the responsibility of the implementor. That's why I would like to know how such cooperative functionality can be implemented, by perhaps less tricky means. sorry, but I fail to see the problem ? The above makes all protected members of a class visible. This is normal, that is why they are protected. If you want to avoid that, make the members private. Then they are visible only in the same unit, even for other classes (for 'cooperation'), but not outside the unit, even with a descendent. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel C++ requires "friend" only because it lacks the idea of modularity. Since all classes are "apart" they need some way to tell each other "I can use you" In pascal you simply put them into 1 unit. Ales ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Changing transaction properties specific to IB when using IBConnection
On Fri, 18 Mar 2005, Michalis Kamburelis wrote: Hi I played with Sqldb and IBConnection units, and now I see the real benefit of them: there's only one dataset and one transaction class for all Firebird, PostgreSQL and MySQL bindings. Each specific database "binding" must only introduce new TSQLConnection descendant. It's great since it gives me even easier switching between various databases. This reminds me the zeos project. However, there's a problem. In real programs I want to be able to set some FB-specific transaction parameters. By doing this I'm agreeing to sacrifice some portability of my programs across various databases, but I think it's useful, at least with FB, since there are many sensible transaction isolation modes and I want to be able to choose what I want. When I was playing with Interbase unit yesterday, this was simple, much like with Delphi's IBX: just set appropriate properties of TIBTransaction class, like IsolationLevel. How to get equivalent functionality with Sqldb and IBConnection ? I would propose to introduce a enumerated TSQLTransactionStyle =(tsConcurrent,tsReadCommit, etc.); Then add a TransactionStyle to TSQLTransaction; This must be mapped by the TSQLConnection when creating the handle. I implemented some small patches that enable this. The essential thing is new public function TSQLTransaction.SQLHandle that gives an access to TIBTrans class specific to FB database. Note that this forced me to write some additional code to react when user changes value of TSQLConnection.Database property. User of this code must be prepared that changing TSQLConnection.Database resets properties of SQLHandle. An event 'AfterGetSQLHandle' could be introduced in TTransaction. But I think the abo ( Some notes about the problem with resetting properties of SQLHandle: This problem is (at least partially) inevitable, since when value of Database property changes, it may change to a different descendant of TSQLConnection so the set of available properties may change anyway. So I think that the current method (that will implicitly reset all properties of SQLHandle, because internally FTrans will be destroyed and then (at the next call to SQLHandle) created again) is OK. ) Now I can change properties of FB transaction doing e.g. (SQLTransaction.SQLHandle as TIBTrans).IsolationLevel := ilReadCommitted; Attached patch also fixes a small bug, by changing in TSQLQuery.InternalOpen FieldByName to FindField. See inside the patch for comments what it solves. One more thing: note that default IsolationLevel of IBConnection.TIBTrans is ilConcurrent, while default IsolationLevel of Interbase.TIBTransaction is ilReadCommitted. It's not my fault :), that's the way they were done. And none of my patches tries to change it, since it would be an incompatible change. However, I would advice changing default IsolationLevel of Interbase.TIBTransaction to ilConcurrent. This way not only IBConnection and Interbase units would use the same IsolationLevel by default, but also this would make Interbase.TIBTransaction a little more compatible to Delphi's IBX and to standard FB behaviour (empty TPB passed to isc_start_transaction is equivalent to isc_tpb_concurrency). This can be done. None of the DB components are 'fixed', i.e. you are free to submit patches, suggest changes etc. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] "Friend" classes?
On Wed, 16 Mar 2005, DrDiettrich wrote: Michael Van Canneyt wrote: type TFriendClass = class(TNotMyClass); This is a simple descendent. Yes and no. The only purpose of this declaration is to get access to the protected members of the class, not to extend the class in any way. Yes. This is OK, no ? 3) What alternatives could be used, so that not all class members must be made public, when they shall be used only in specific related units? ? Please explain. "protected" members of a class are for internal use only, not for public use. IMO it's against the spirit of visibility levels, when the protected and even private members of a class become accessible from outside the class, throughout the whole unit in which a class is defined. But sometimes multiple classes are designed for cooperation, where one class needs access to not normally accessible methods or properties of another class. When now the required methods are made public, they become available for abuse by everybody. With the above trick instead it's possible to gain access to the internals of a class, without making everything public. Such a backdoor does not prevent abuse, but as the (C++) term "friend" class suggests, it exists only for the sake of cooperation, and at the responsibility of the implementor. That's why I would like to know how such cooperative functionality can be implemented, by perhaps less tricky means. sorry, but I fail to see the problem ? The above makes all protected members of a class visible. This is normal, that is why they are protected. If you want to avoid that, make the members private. Then they are visible only in the same unit, even for other classes (for 'cooperation'), but not outside the unit, even with a descendent. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] "Friend" classes?
Michael Van Canneyt wrote: > > type TFriendClass = class(TNotMyClass); > > This is a simple descendent. Yes and no. The only purpose of this declaration is to get access to the protected members of the class, not to extend the class in any way. > > 3) What alternatives could be used, so that not all class members must > > be made public, when they shall be used only in specific related units? > > ? Please explain. "protected" members of a class are for internal use only, not for public use. IMO it's against the spirit of visibility levels, when the protected and even private members of a class become accessible from outside the class, throughout the whole unit in which a class is defined. But sometimes multiple classes are designed for cooperation, where one class needs access to not normally accessible methods or properties of another class. When now the required methods are made public, they become available for abuse by everybody. With the above trick instead it's possible to gain access to the internals of a class, without making everything public. Such a backdoor does not prevent abuse, but as the (C++) term "friend" class suggests, it exists only for the sake of cooperation, and at the responsibility of the implementor. That's why I would like to know how such cooperative functionality can be implemented, by perhaps less tricky means. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Local procedures as procedural parameter
[EMAIL PROTECTED] wrote: > > > Let me add some more thoughts about procedural types: > > > > - I like the ability to declare procedural types, the ISO convention > > looks like one of the many incredible C hacks to me :-( > > But it is standard pascal. And we need to support those zillion lines of > code out there, written in standard pascal. Agreed, as far as I'm not pressed myself, to use constructs that I don't like ;-) > > - For the restricted use of local subroutines as procedural parameters I > > could imagine a "const" prefix in the accepting procedure declaration: > > > > procedure my_fun(const pf: tfun); > > This will be unclear imo, I would prefer a directive which tells what it > really is about. Such an explicit directive would not be portable, unless introduced by some accepted standard. > > Hmm, the hidden frame parameter still will make a difference with local > > subroutines. At least in Pascal calling convention, where the arguments > > are popped by the called subroutine, not by the caller... > > The pascal calling convention is not used on most modern processors, since > parameters instead are passed in registers. I'd be careful with "most", the most frequently used "modern" processor has anything but a modern architecture. But unfortunately the bundling of bad hardware with bad software seems to be what the consumer market appreciates :-( DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
