Activity for Hunter Payne
-
Hunter Payne posted a comment on ticket #10
To aid in the porting process, you can probably remove the execute method from porting the command objects (it was a bad idea to link the two ideas). The command objects exist to bridge from JDBC (or a JDBC like API) calls to an object and then the CommandSink does the conversion (via Java Serialization or some other mechanism) and transport to the server and back again. The hard part is if your target server uses Java Serialization (RMI does this, HTTP doesn't) in which case you have to bake your...
-
Well, that's a lot of work. To do that, you probably would first port the de.simplicit.vjdbc.command package to .NET and then the Virtual driver classes (classes with a name like de.simplicit.vjdbc.Virtual*). The rest would be porting over classes that those two sets of classes need. The code isn't separated properly into different dependent jars which would enforce separating the client and server classes which always bugged me but wasn't a real problem (it would help here). Make sure you read the...
-
There is no reason you couldn't write a .NET client side implementation of vJDBC's functionality and it could talk to a server using vJDBC and the existing protocol. So in that case a normal DB using vJDBC could talk to a .NET implementation speaking the same protocol. Otherwise vJDBC is a JVM only implementation (as its 100% Java). Hunter On Friday, June 8, 2018, 8:08:35 PM PDT, Gagan Sharma gagansharma7@users.sourceforge.net wrote: [support-requests:#10] VJDBC driver using .Net Status: open Group:...
1