gmane.comp.db.metakit

you got your database in my Python remote objects server


just want to throw this idea out and see it in appeal to anyone.  I would work 
on it myself except for the fact that my wrists have given out (yet again) and 
writing code with speech recognition isn't the most efficient method.

I have been working on a project where I am using Pyro (Python remote objects) 
as a way of providing network access to a variety of operations on top of 
database services.  I have been struggling with a variety of database techniques 
and I keep coming back to metakit as a solution that just feels right in terms 
of level of effort etc.

The main problem is that Python remote object servers are multithreaded.  They 
are either threaded on an object basis or connection basis.  Everything I've 
read so far says that metakit is maybe yes, maybe no, happy with threads in the 
Python environment.

My wish: update/validate metakit to work with threads in general and Pyro 
servers specifically.  I'm not asking for a lot. Metakit access could be single 
threaded which still allows for server applications to be multithreaded.  I 
believe that something this "simple" would be good because, in theory, it's 
either present but on validated or relatively easy to accomplish.  in addition 
to this wish, I would like to see a release of a thread capable/okay metakit in 
conjunction with Pyro 4.0.  A joint project/release would bring good, positive 
attention to both projects.

If folks think it's a good idea, what would it take to validate metakit in a 
threaded environment like the one I propose?  Is there a simpler model for 
dealing with threaded environments that I'm not aware of?

I have templates for Pyro servers that I could use to help build a testbed but

(Continue reading)

headers

David McNab | 28 Sep 22:36

Re: you got your database in my Python remote objects server

On Fri, 2007-09-28 at 13:58 -0400, Eric S. Johansson wrote:
> If folks think it's a good idea, what would it take to validate metakit in a 
> threaded environment like the one I propose?  Is there a simpler model for 
> dealing with threaded environments that I'm not aware of?

Thinking more broadly, have you specifically ruled out using an object
interface to a common SQL database, such as SQLObject over MySQL?

That combination is extremely thread-safe, and gives the remote clients
an excellent object view of tables, columns, rows etc. And it's pretty
easy to use.

If this doesn't appeal, and you're feeling pretty determined to access
metakit remotely, then have you figured out a clear definition of
exactly what kind of 'look and feel' you want on the client side?

If your 'look and feel' requirements aren't too demanding, then it
should be possible to set up a Queue-based multithread setup on the
server, such that only one of the server threads is accessing the actual
metakit database, and other threads which talk to the remote client
communicate with this one thread. This wouldn't require any mods to
metakit or Pyro - just an access layer.

Cheers
David

> 
> I have templates for Pyro servers that I could use to help build a testbed but 
> I'm missing some critical knowledge to be able to complete the project.

(Continue reading)

headers

Eric S. Johansson | 28 Sep 23:09

Re: you got your database in my Python remote objects server

David McNab wrote:
> On Fri, 2007-09-28 at 13:58 -0400, Eric S. Johansson wrote:
>> If folks think it's a good idea, what would it take to validate metakit in a 
>> threaded environment like the one I propose?  Is there a simpler model for 
>> dealing with threaded environments that I'm not aware of?
> 
> Thinking more broadly, have you specifically ruled out using an object
> interface to a common SQL database, such as SQLObject over MySQL?

my only objection to SQL is that it typically takes me five to 10 times longer 
to solve a problem using SQL.  I don't know why I have this mental block but it 
is an absolute horrific experience I wouldn't wish my worst enemy.
> 
> That combination is extremely thread-safe, and gives the remote clients
> an excellent object view of tables, columns, rows etc. And it's pretty
> easy to use.

it's also fat, clumsy, hard to use, etc. etc.  Using an mySQL database in a 
startup where I was a founder and small-scale funder cost me almost $50,000 and 
a year of my life.  I've also used SQL and make a few more projects and they all 
took weeks and months longer than dbm based hacks.  They also didn't run that 
much faster.

> If this doesn't appeal, and you're feeling pretty determined to access
> metakit remotely, then have you figured out a clear definition of
> exactly what kind of 'look and feel' you want on the client side?

I'm sorry that I did not express myself well.  I do not want to access metakit 
remotely.  I want to stick metakit in a framework so that it can be used as a

(Continue reading)