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:
Thanks for the prompt reply Hunter.
Could you please also help in letting me know the steps like which driver
to download, any sample code etc. Will there be a different vjdbc driver
for connecting to oracle db and different for connecting to sql server or
mysql?
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:
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 description of how the vJDBC protocol works. Basically, those classes in the command package all represent a single protocol message which in turn represents a single JDBC method call. You need .NET code that sends those same messages to a server and reads back the response messages from the server.
The upshot of all of this is that the vJDBC protocol is separate from the actual wire protocol. The only thing vJDBC really cares about is sending those command objects back and forth to the server. This means that the server can receive those command objects via any network protocol (RMI, HTTP, etc). Its just that you need to make your client speak whatever wire protocol your targeted server speaks to send/receive those command objects.
If you want to take this on, I would humbly invite you to put your client into the vJDBC repo. That way I can review the code and make suggestions but I understand if that's not possible for you. Its just harder for me to answer questions in that case.
Hunter
PS If this has to do with SQLStream or Blaze, don't bother...those drivers use a custom version of the vJDBC protocol with a custom wire protocol which is why its so very very fast
On Saturday, June 9, 2018, 4:52:58 AM PDT, Gagan Sharma <gagansharma7@users.sourceforge.net> wrote:
Thanks for the prompt reply Hunter.
Could you please also help in letting me know the steps like which driver
to download, any sample code etc. Will there be a different vjdbc driver
for connecting to oracle db and different for connecting to sql server or
mysql?
Regards
Gagan
On 1:58AM, Sat, Jun 9, 2018 Hunter Payne sfcat@users.sourceforge.net
wrote:
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:
Thanks for your useful suggestions. I might be able to start on my efforts
next week and will post my code. I will be using Visual Studio 2017 and
will make sure to import the classes you suggested.
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 description of how the vJDBC protocol works.
Basically, those classes in the command package all represent a single
protocol message which in turn represents a single JDBC method call. You
need .NET code that sends those same messages to a server and reads back
the response messages from the server.
The upshot of all of this is that the vJDBC protocol is separate from the
actual wire protocol. The only thing vJDBC really cares about is sending
those command objects back and forth to the server. This means that the
server can receive those command objects via any network protocol (RMI,
HTTP, etc). Its just that you need to make your client speak whatever wire
protocol your targeted server speaks to send/receive those command objects.
If you want to take this on, I would humbly invite you to put your client
into the vJDBC repo. That way I can review the code and make suggestions
but I understand if that's not possible for you. Its just harder for me to
answer questions in that case.
Hunter
PS If this has to do with SQLStream or Blaze, don't bother...those drivers
use a custom version of the vJDBC protocol with a custom wire protocol
which is why its so very very fast
Thanks for the prompt reply Hunter.
Could you please also help in letting me know the steps like which driver
to download, any sample code etc. Will there be a different vjdbc driver
for connecting to oracle db and different for connecting to sql server or
mysql?
Regards
Gagan
On 1:58AM, Sat, Jun 9, 2018 Hunter Payne sfcat@users.sourceforge.net
wrote:
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:
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 own Java Serialization clone in .NET for all the Command objects.
Hunter
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: v1.0 (example)
Created: Sat Jun 09, 2018 03:08 AM UTC by Gagan Sharma
Last Updated: Sat Jun 09, 2018 03:08 AM UTC
Owner: nobody
hi, could someone suggest if VJDBC driver can be used to connect to a database in .net?
thanks
Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/vjdbc/support-requests/10/
To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/
Related
Support Requests: #10
Thanks for the prompt reply Hunter.
Could you please also help in letting me know the steps like which driver
to download, any sample code etc. Will there be a different vjdbc driver
for connecting to oracle db and different for connecting to sql server or
mysql?
Regards
Gagan
On 1:58AM, Sat, Jun 9, 2018 Hunter Payne sfcat@users.sourceforge.net
wrote:
Related
Support Requests: #10
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 description of how the vJDBC protocol works. Basically, those classes in the command package all represent a single protocol message which in turn represents a single JDBC method call. You need .NET code that sends those same messages to a server and reads back the response messages from the server.
The upshot of all of this is that the vJDBC protocol is separate from the actual wire protocol. The only thing vJDBC really cares about is sending those command objects back and forth to the server. This means that the server can receive those command objects via any network protocol (RMI, HTTP, etc). Its just that you need to make your client speak whatever wire protocol your targeted server speaks to send/receive those command objects.
If you want to take this on, I would humbly invite you to put your client into the vJDBC repo. That way I can review the code and make suggestions but I understand if that's not possible for you. Its just harder for me to answer questions in that case.
Hunter
PS If this has to do with SQLStream or Blaze, don't bother...those drivers use a custom version of the vJDBC protocol with a custom wire protocol which is why its so very very fast
Thanks for the prompt reply Hunter.
Could you please also help in letting me know the steps like which driver
to download, any sample code etc. Will there be a different vjdbc driver
for connecting to oracle db and different for connecting to sql server or
mysql?
Regards
Gagan
On 1:58AM, Sat, Jun 9, 2018 Hunter Payne sfcat@users.sourceforge.net
wrote:
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]
https://sourceforge.net/p/vjdbc/support-requests/10/ VJDBC driver using
.Net
Status: open
Group: v1.0 (example)
Created: Sat Jun 09, 2018 03:08 AM UTC by Gagan Sharma
Last Updated: Sat Jun 09, 2018 03:08 AM UTC
Owner: nobody
hi, could someone suggest if VJDBC driver can be used to connect to a
database in .net?
thanks
Sent from sourceforge.net because you indicated interest in
https://sourceforge.net/p/vjdbc/support-requests/10/
To unsubscribe from further messages, please visit
https://sourceforge.net/auth/subscriptions/
https://sourceforge.net/p/vjdbc/support-requests/10/ VJDBC driver using
.Net*
Status: open
Group: v1.0 (example)
Created: Sat Jun 09, 2018 03:08 AM UTC by Gagan Sharma
Last Updated: Sat Jun 09, 2018 03:08 AM UTC
Owner: nobody
hi, could someone suggest if VJDBC driver can be used to connect to a
database in .net?
thanks
Sent from sourceforge.net because you indicated interest in
https://sourceforge.net/p/vjdbc/support-requests/10/
To unsubscribe from further messages, please visit
https://sourceforge.net/auth/subscriptions/
[support-requests:#10] VJDBC driver using .Net
Status: open
Group: v1.0 (example)
Created: Sat Jun 09, 2018 03:08 AM UTC by Gagan Sharma
Last Updated: Sat Jun 09, 2018 03:08 AM UTC
Owner: nobody
hi, could someone suggest if VJDBC driver can be used to connect to a database in .net?
thanks
Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/vjdbc/support-requests/10/
To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/
Related
Support Requests: #10
Hello Hunter
Thanks for your useful suggestions. I might be able to start on my efforts
next week and will post my code. I will be using Visual Studio 2017 and
will make sure to import the classes you suggested.
Regards
Gagan
On Sat, Jun 9, 2018, 1:22 PM Hunter Payne sfcat@users.sourceforge.net
wrote:
Related
Support Requests: #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 own Java Serialization clone in .NET for all the Command objects.
Hunter