some questions

[lekma]

Hi all,

1. given the following extent definition:

class Lang(E.Entity):
code = f.unicode()

_key(code)
_index(code)

how come i can create two instance of the Lang entity with the same
code value?
fwiw, if i remove the index specification, then the key specification
is enforced.

2. if i specify a key does automatically imply an index specification?

3. what about concurrent access/transactions, how are they handled?

4. is there any plan to "wrap" a server around shevo?

5. is there an irc channel where schevo dev hang out?

thanks for any help/pointer

lekma

ps: i am a newbie to schevo, and still trying to dig info from the
website, so , please, pardon me if my questions seem stupid.

[Patrick K. O'Brien]

Post by lekma
Hi all,
code = f.unicode()
_key(code)
_index(code)
how come i can create two instance of the Lang entity with the same
code value?
fwiw, if i remove the index specification, then the key specification
is enforced.

That looks like a bug in Schevo. I'll look into that.

Post by lekma
2. if i specify a key does automatically imply an index specification?

Yes, keys are enforced through the creation of a unique index, which is
also used to speed up certain operations.

Post by lekma
3. what about concurrent access/transactions, how are they handled?

Schevo originally came out of Pypersyst, which was a Python port of
Prevayler, which required all transactions to be serial (first logged to
disk, then executed). Since then we have moved to Durus as the
persistence engine, which isn't limited by RAM (Pypersyt and Prevayler
require the entire database to reside in RAM).

One of the ideas that began in Pypersyst, and that we have expanded on
quite a bit in Schevo, is the idea that transactions are objects. That
makes Schevo quite a bit different than traditional databases (although
the evaluation of these transaction objects in Durus does take place
within traditional transaction boundaries).

So far we have focused our efforts on using Schevo as an embedded
database within single-user applications, and to support web
applications. For both of these our transaction model works quite well.
Before moving to Durus we had an experimental multi-user arrangement
that also worked well.

So as of now concurrent access is something that is still on the to-do
list. I do have the book "Transactional Information Systems" by Weikum
and Vossen that should help (if I could ever find the time to actually
read it).

Post by lekma
4. is there any plan to "wrap" a server around shevo?

Durus can be run in a client/server fashion. We would probably use that
as a starting point.

Post by lekma
5. is there an irc channel where schevo dev hang out?

#schevo on freenode

Post by lekma
thanks for any help/pointer

Thank you for pointing out bugs and asking good questions. :-)

Post by lekma
lekma
ps: i am a newbie to schevo, and still trying to dig info from the
website, so , please, pardon me if my questions seem stupid.

No problem. Our documentation is not very good, so please feel free to
ask questions.

[lekma]

forgot to cc the list

Begin forwarded message:

Date: Tue, 16 Jan 2007 12:21:53 +0100
From: lekma <***@chello.nl>
To: "Patrick K. O'Brien" <***@orbtech.com>
Subject: Re: [Schevo-devel] some questions


On Sat, 13 Jan 2007 09:34:54 -0600

Post by Patrick K. O'Brien

Post by lekma
Hi all,
code = f.unicode()
_key(code)
_index(code)
how come i can create two instance of the Lang entity with the same
code value?
fwiw, if i remove the index specification, then the key
specification is enforced.

That looks like a bug in Schevo. I'll look into that.

ok

Post by Patrick K. O'Brien

Post by lekma
2. if i specify a key does automatically imply an index
specification?

Yes, keys are enforced through the creation of a unique index, which
is also used to speed up certain operations.

ok

Post by Patrick K. O'Brien

Post by lekma
3. what about concurrent access/transactions, how are they handled?

Schevo originally came out of Pypersyst, which was a Python port of
Prevayler, which required all transactions to be serial (first logged
to disk, then executed). Since then we have moved to Durus as the
persistence engine, which isn't limited by RAM (Pypersyt and Prevayler
require the entire database to reside in RAM).
One of the ideas that began in Pypersyst, and that we have expanded on
quite a bit in Schevo, is the idea that transactions are objects.
That makes Schevo quite a bit different than traditional databases
(although the evaluation of these transaction objects in Durus does
take place within traditional transaction boundaries).
So far we have focused our efforts on using Schevo as an embedded
database within single-user applications, and to support web
applications. For both of these our transaction model works quite
well. Before moving to Durus we had an experimental multi-user
arrangement that also worked well.

that raises the question as to why did you embed durus? why not rely on
an external module? do you keep in sync with durus changes?

Post by Patrick K. O'Brien
So as of now concurrent access is something that is still on the to-do
list. I do have the book "Transactional Information Systems" by
Weikum and Vossen that should help (if I could ever find the time to
actually read it).

that would be a huge plus

Post by Patrick K. O'Brien

Post by lekma
4. is there any plan to "wrap" a server around shevo?

Durus can be run in a client/server fashion. We would probably use
that as a starting point.

the fact that durus can be accessed in client/server way is nice for
schevo, because you can probably run more than one schevo "server"
against one durus db (think load balancing, n-tier app, etc), but i was
thinking more of the other side of the story. i.e. client/server access
to shevo, which would allow the clien _not_ to require embedding schevo.

anyway, i've discovered the asyn branch in svn, and it seems to be what
i was looking for. the question is: is it in sync with the trunk? are
there any plans to integrate it in trunk? is there a todo list of
what's left to be done (maybe i can pickup some items and help)?

Post by Patrick K. O'Brien

Post by lekma
5. is there an irc channel where schevo dev hang out?

#schevo on freenode

well, there doesn't seem to be much hanging there :) (or i'm in the
wrong channel, or the wrong time window, or...)

Post by Patrick K. O'Brien

Post by lekma
thanks for any help/pointer

Thank you for pointing out bugs and asking good questions. :-)

Post by lekma
lekma
ps: i am a newbie to schevo, and still trying to dig info from the
website, so , please, pardon me if my questions seem stupid.

No problem. Our documentation is not very good, so please feel free
to ask questions.

[Patrick K. O'Brien]

Post by lekma

Post by Patrick K. O'Brien
So far we have focused our efforts on using Schevo as an embedded
database within single-user applications, and to support web
applications. For both of these our transaction model works quite
well. Before moving to Durus we had an experimental multi-user
arrangement that also worked well.

that raises the question as to why did you embed durus? why not rely on
an external module? do you keep in sync with durus changes?

There are a couple of reasons why we maintain a fork of Durus. The
original reason is that we started using Durus before setuptools and
eggs and wanted to keep things simple for users of Schevo. I also
believe very strongly in protecting the data that Schevo is used to
maintain. We were also able to fix a few bugs when using Durus on
Windows. And we introduced some features (like the use of slots) before
they became available in Durus. And the final reason is that I'm still
holding onto the idea that we have an opportunity to optimize Durus for
the particular way that Schevo makes use of it.

I think we have a great relationship with the Durus folks (I'm looking
forward to seeing them again at PyCon). Durus is meant to be a general
tool to solve the needs of many. Schevo makes use of it in a very
specific way that is most likely different than the way everyone else
uses it. So for now we will continue to maintain a "friendly fork".

As for versions, we are one version behind the current version of Durus.

Post by lekma

Post by Patrick K. O'Brien

Post by lekma
4. is there any plan to "wrap" a server around shevo?

Durus can be run in a client/server fashion. We would probably use
that as a starting point.

the fact that durus can be accessed in client/server way is nice for
schevo, because you can probably run more than one schevo "server"
against one durus db (think load balancing, n-tier app, etc), but i was
thinking more of the other side of the story. i.e. client/server access
to shevo, which would allow the clien _not_ to require embedding schevo.
anyway, i've discovered the asyn branch in svn, and it seems to be what
i was looking for. the question is: is it in sync with the trunk? are
there any plans to integrate it in trunk? is there a todo list of
what's left to be done (maybe i can pickup some items and help)?

Matt created that branch and will hopefully have time to join this
discussion. In the mean time, take a look at the files in the doc
directory of that branch where Matt describes his concept and has some
doctest examples.

And we'd love to have some help with these things. Just let us know
what you'd like to work on and we can help you get started.

Post by lekma

Post by Patrick K. O'Brien

Post by lekma
5. is there an irc channel where schevo dev hang out?

#schevo on freenode

well, there doesn't seem to be much hanging there :) (or i'm in the
wrong channel, or the wrong time window, or...)

I suspect we're in much different timezones. Matt and I are in CST,
which is UTC-6. Where are you?