Jamu Kakar | 4 Dec 2009 00:08
Picon
Gravatar

Re: Announcing Storm 0.16!

Hi,

On Sun, Nov 29, 2009 at 12:17 PM, Jamu Kakar <jkakar <at> kakar.ca> wrote:
> I've just discovered that the karmic (and probably lucid) packages
> don't work quite right.  I tested on hardy and everything worked. :/
> The issue is that, on karmic, /usr/lib/python2.6/site-packages is
> not included in sys.path, by default, but this is where the package
> installs Storm files.  It appears that they need to be installed in
> /usr/lib/python2.6/dist-packages for things to work correctly.

I've built new packages that resolve this issue.  I've tested on
karmic and things work fine.  Please report any problems you
discover.

Sorry for any inconvenience this has caused.

Thanks,
J.

--

-- 
storm mailing list
storm <at> lists.canonical.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/storm
Jamu Kakar | 4 Dec 2009 00:13
Picon
Gravatar

New lp:~storm/storm/packaging branch

Hi,

I've removed the debian directory from the lp:storm branch.  I've
created a new lp:~storm/storm/packaging branch that has the debian
packaging files.  I've used it to prepare the latest fixed 0.16
packages and will use it from now on for future builds.  This will
keep package-related changes and build revisions out of the mainline
history.

Thanks,
J.

Jason Baker | 4 Dec 2009 15:33
Favicon

Re: New lp:~storm/storm/packaging branch

Just out of sheer curiosity, what is the purpose of this change?  What advantages are there to doing things that way?

On Thu, Dec 3, 2009 at 5:13 PM, Jamu Kakar <jkakar-kvr/BIsI4Rg@public.gmane.org> wrote:
Hi,

I've removed the debian directory from the lp:storm branch.  I've
created a new lp:~storm/storm/packaging branch that has the debian
packaging files.  I've used it to prepare the latest fixed 0.16
packages and will use it from now on for future builds.  This will
keep package-related changes and build revisions out of the mainline
history.

Thanks,
J.

--
storm mailing list
storm-33AaDErTWvAAkhNd+W/JZ0EOCMrvLtNR@public.gmane.org
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/storm



--
ZeOmega
Open Minds' Open Solutions
3010 Gaylord Parkway, Ste. 210
Frisco TX, 75034
http://www.zeomega.com

Jason Baker
214-618-9880 (ext. 8024)

"Program testing can be a very effective way to show the presence of bugs, but it is hopelessly inadequate for showing their absence." (Dijkstra)
<div>
<p>Just out of sheer curiosity, what is the purpose of this change? &nbsp;What advantages are there to doing things that way?<br><br></p>
<div class="gmail_quote">On Thu, Dec 3, 2009 at 5:13 PM, Jamu Kakar <span dir="ltr">&lt;<a href="mailto:jkakar@...">jkakar@...</a>&gt;</span> wrote:<br><blockquote class="gmail_quote">Hi,<br><br>
I've removed the debian directory from the lp:storm branch. &nbsp;I've<br>
created a new lp:~storm/storm/packaging branch that has the debian<br>
packaging files. &nbsp;I've used it to prepare the latest fixed 0.16<br>
packages and will use it from now on for future builds. &nbsp;This will<br>
keep package-related changes and build revisions out of the mainline<br>
history.<br><br>
Thanks,<br>
J.<br><br>
--<br>
storm mailing list<br><a href="mailto:storm@...">storm@...</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/storm" target="_blank">https://lists.ubuntu.com/mailman/listinfo/storm</a><br>
</blockquote>
</div>
<br><br clear="all"><br>-- <br>ZeOmega<br>Open Minds' Open Solutions<br>3010 Gaylord Parkway, Ste. 210<br>Frisco TX, 75034<br><a href="http://www.zeomega.com">http://www.zeomega.com</a><br><br>
Jason Baker<br>214-618-9880 (ext. 8024)<br><br>"Program testing can be a very effective way to show the presence of bugs, but it is hopelessly inadequate for showing their absence." (Dijkstra)<br>
</div>
Jamu Kakar | 4 Dec 2009 17:05
Picon
Gravatar

Re: New lp:~storm/storm/packaging branch

Hi Jason,

On Fri, Dec 4, 2009 at 6:33 AM, Jason Baker <jbaker <at> zeomega.com> wrote:
> Just out of sheer curiosity, what is the purpose of this change?  What
> advantages are there to doing things that way?

The primary purpose of the change, at least the reason I made it, is
to keep the mainline history clean.  I use AutoPPA to build packages
and if you look back in the history you'll see fair amount of noise
created as a result of AutoPPA merging changes made to produce a
build back into trunk.  Using a separate packaging branch alleviates
this and keeps trunk a pure upstream branch.  It's a pattern that
subunit uses, and I think Bazaar too.

I've been told by real packagers (I'm mostly a faker) that this kind
of separation is preferred because it's somehow easier for them to
make changes.  I don't fully understand why this is, to be honest.

Anyway, preparation for the release such updating the NEWS file,
bumping version numbers and so on will still happen in trunk.
Release tarballs will still be created from trunk.  When this
happens trunk will be merged to packaging and packages builds will
be made.

Hope this helps,
J.

--

-- 
storm mailing list
storm <at> lists.canonical.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/storm
Jason Baker | 4 Dec 2009 23:43
Favicon

Oracle sequence columns

One thing we'd like to have in storm is the ability to specify a sequence that we can use by default on primary keys.  For instance, suppose I have a class like this:


    class Foo(object):
        __storm_table__ = 'foo'
        foo_pk = Int(primary=True)

If we want foo_pk to autoincrement on Oracle, our only option is to define a trigger that will call nextval on the sequence.  It would be nice to be able to do something like this:

    class Foo(object):
        __storm_table__ = 'foo'
        foo_pk = Int(primary=True, sequence_name='foo_seq')

This way, when I insert a new Foo, it will automatically pull from foo_seq and I don't have to define a trigger.  Of course for this to be useful, other platforms would need to ignore that keyword argument.  I'd be willing to work on this if someone could give me some feedback into the best way to implement this.
<div>
<p>One thing we'd like to have in storm is the ability to specify a sequence that we can use by default on primary keys. &nbsp;For instance, suppose I have a class like this:
</p>
<div><br></div>
<div>&nbsp;&nbsp; &nbsp;class Foo(object):</div>
<div>&nbsp;&nbsp; &nbsp; &nbsp; &nbsp;__storm_table__ = 'foo'</div>
<div>&nbsp;&nbsp; &nbsp; &nbsp; &nbsp;foo_pk = Int(primary=True)</div>
<div><br></div>
<div>If we want foo_pk to autoincrement on Oracle, our only option is to define a trigger that will call nextval on the sequence. &nbsp;It would be nice to be able to do something like this:</div>
<div><br></div>
<div>&nbsp;&nbsp; &nbsp;class Foo(object):</div>
<div>&nbsp;&nbsp; &nbsp; &nbsp; &nbsp;__storm_table__ = 'foo'</div>
<div>&nbsp;&nbsp; &nbsp; &nbsp; &nbsp;foo_pk = Int(primary=True, sequence_name='foo_seq')</div>
<div><br></div>
<div>This way, when I insert a new Foo, it will automatically pull from foo_seq and I don't have to define a trigger. &nbsp;Of course for this to be useful, other platforms would need to ignore that keyword argument. &nbsp;I'd be willing to work on this if someone could give me some feedback into the best way to implement this.</div>
</div>
Jamu Kakar | 5 Dec 2009 00:31
Picon
Gravatar

Re: Oracle sequence columns

Hi Jason,

On Fri, Dec 4, 2009 at 2:43 PM, Jason Baker <jbaker <at> zeomega.com> wrote:
> One thing we'd like to have in storm is the ability to specify a sequence
> that we can use by default on primary keys.  For instance, suppose I have a
> class like this:
>     class Foo(object):
>         __storm_table__ = 'foo'
>         foo_pk = Int(primary=True)
> If we want foo_pk to autoincrement on Oracle, our only option is to define a
> trigger that will call nextval on the sequence.  It would be nice to be able
> to do something like this:
>     class Foo(object):
>         __storm_table__ = 'foo'
>         foo_pk = Int(primary=True, sequence_name='foo_seq')
> This way, when I insert a new Foo, it will automatically pull from foo_seq
> and I don't have to define a trigger.  Of course for this to be useful,
> other platforms would need to ignore that keyword argument.  I'd be willing
> to work on this if someone could give me some feedback into the best way to
> implement this.

I don't really understand how Oracle works, so I might be off base
here, but isn't this a schema management problem?  In other words,
do you need Storm to issue a particular query whenever you perform
an insert to get autoincrement behaviour or do you just need to
define a trigger as part of your schema?

Thanks,
J.

--

-- 
storm mailing list
storm <at> lists.canonical.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/storm
Jamu Kakar | 5 Dec 2009 02:19
Picon
Gravatar

Re: Oracle sequence columns

Hi Vernon,

On Fri, Dec 4, 2009 at 5:11 PM, Vernon Cole <vernondcole <at> gmail.com> wrote:
> Some syntax like this would be REALLY helpful for supporting MS SQL,
> too.  MS will increment the value for you, but then you need to ask it
> to tell you what number it assigned.  A clue that we have an
> autoincrement field would tell us when to go hunting for the new
> value.

I don't think this is actually necessary.  Each backend is able to,
as needed, provide support for this behaviour (for primary keys).
Search for get_insert_identity if you're curious about the way this
works.

Thanks,
J.

--

-- 
storm mailing list
storm <at> lists.canonical.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/storm
Jason Baker | 5 Dec 2009 17:38
Favicon

Re: Oracle sequence columns

On Fri, Dec 4, 2009 at 5:31 PM, Jamu Kakar <jkakar <at> kakar.ca> wrote:
Hi Jason,

On Fri, Dec 4, 2009 at 2:43 PM, Jason Baker <jbaker-QHTyk4n1zzFBDgjK7y7TUQ@public.gmane.org> wrote:
> One thing we'd like to have in storm is the ability to specify a sequence
> that we can use by default on primary keys.  For instance, suppose I have a
> class like this:
>     class Foo(object):
>         __storm_table__ = 'foo'
>         foo_pk = Int(primary=True)
> If we want foo_pk to autoincrement on Oracle, our only option is to define a
> trigger that will call nextval on the sequence.  It would be nice to be able
> to do something like this:
>     class Foo(object):
>         __storm_table__ = 'foo'
>         foo_pk = Int(primary=True, sequence_name='foo_seq')
> This way, when I insert a new Foo, it will automatically pull from foo_seq
> and I don't have to define a trigger.  Of course for this to be useful,
> other platforms would need to ignore that keyword argument.  I'd be willing
> to work on this if someone could give me some feedback into the best way to
> implement this.

I don't really understand how Oracle works

One thing that's important to understand is that Oracle doesn't have any way to define an IDENTITY/AUTOINCREMENT field.  You may or may not already know this, I just thought it would be good to mention it in case you didn't.  :-)
 
 In other words,
do you need Storm to issue a particular query whenever you perform
an insert to get autoincrement behaviour or do you just need to
define a trigger as part of your schema?
 
In Oracle circles, a trigger is considered to be a hacky workaround for applications that aren't able to work with sequences.  Here's how it would work.  Suppose I define a table and sequence like this:

    CREATE TABLE foo(
    foo_pk INT PRIMARY KEY);

    CREATE SEQUENCE foo_seq;

I can make the table foo use foo_seq one of two ways:

 1.  I can define a trigger that will automatically get a value from foo_seq every time a row is inserted
 2.  I can write the INSERT query like this:

    INSERT INTO foo(foo_pk) VALUES (foo_seq.nextval);

Of course, Storm has a way of compiling sequences.  But unless I'm missing something, the only real way to take advantage of that would be something like this:


    foo_row = Foo()
    if db_platform == 'oracle':
        foo_row.foo_pk = Sequence('foo_seq')
    store.add(foo_row)

But it would be nice to have a way of defining a column that will get its value from a particular sequence automatically.

Another idea that just occurred to me is that most of the time, sequences will be defined by giving the table name plus some kind of suffix like "_seq".  So it would save a *lot* of tedium if I could do something like this:

SequenceProperty = sequencemaker(suffix='_seq')

class Foo(object):
    __storm_table__ = 'foo'

    # assume the sequence will be named 'foo_seq' since the table is named foo
    foo_pk = SequenceProperty(primary=True, datatype=Int)

And have backends like MySQL, SQL Server, and SQLite ignore the fact that it's a Sequence property
<div><div class="gmail_quote">On Fri, Dec 4, 2009 at 5:31 PM, Jamu Kakar <span dir="ltr">&lt;<a href="mailto:jkakar@..." target="_blank">jkakar <at> kakar.ca</a>&gt;</span> wrote:<br><blockquote class="gmail_quote">

Hi Jason,<br><div>
<div></div>
<div>
<br>
On Fri, Dec 4, 2009 at 2:43 PM, Jason Baker &lt;<a href="mailto:jbaker <at> zeomega.com" target="_blank">jbaker@...</a>&gt; wrote:<br>
&gt; One thing we'd like to have in storm is the ability to specify a sequence<br>
&gt; that we can use by default on primary keys. &nbsp;For instance, suppose I have a<br>
&gt; class like this:<br>
&gt; &nbsp;&nbsp; &nbsp;class Foo(object):<br>
&gt; &nbsp;&nbsp; &nbsp; &nbsp; &nbsp;__storm_table__ = 'foo'<br>
&gt; &nbsp;&nbsp; &nbsp; &nbsp; &nbsp;foo_pk = Int(primary=True)<br>
&gt; If we want foo_pk to autoincrement on Oracle, our only option is to define a<br>
&gt; trigger that will call nextval on the sequence. &nbsp;It would be nice to be able<br>
&gt; to do something like this:<br>
&gt; &nbsp;&nbsp; &nbsp;class Foo(object):<br>
&gt; &nbsp;&nbsp; &nbsp; &nbsp; &nbsp;__storm_table__ = 'foo'<br>
&gt; &nbsp;&nbsp; &nbsp; &nbsp; &nbsp;foo_pk = Int(primary=True, sequence_name='foo_seq')<br>
&gt; This way, when I insert a new Foo, it will automatically pull from foo_seq<br>
&gt; and I don't have to define a trigger. &nbsp;Of course for this to be useful,<br>
&gt; other platforms would need to ignore that keyword argument. &nbsp;I'd be willing<br>
&gt; to work on this if someone could give me some feedback into the best way to<br>
&gt; implement this.<br><br>
</div>
</div>I don't really understand how Oracle works</blockquote>
<div><br></div>
<div>One thing that's important to understand is that Oracle doesn't have any way to define an IDENTITY/AUTOINCREMENT field. &nbsp;You may or may not already know this, I just thought it would be good to mention it in case you didn't. &nbsp;:-)</div>

<div>&nbsp;</div>
<blockquote class="gmail_quote"> &nbsp;In other words,<br>
do you need Storm to issue a particular query whenever you perform<br>
an insert to get autoincrement behaviour or do you just need to<br>
define a trigger as part of your schema?<br>
</blockquote>
<div>&nbsp;</div>
<div>In Oracle circles, a trigger is considered to be a hacky workaround for applications that aren't able to work with sequences. &nbsp;Here's how it would work. &nbsp;Suppose I define a table and sequence like this:</div>

<div><br></div>
<div>&nbsp;&nbsp; &nbsp;CREATE TABLE foo(</div>
<div>&nbsp;&nbsp; &nbsp;foo_pk INT PRIMARY KEY);</div>
<div><br></div>
<div>&nbsp;&nbsp; &nbsp;CREATE SEQUENCE foo_seq;</div>
<div><br></div>
<div>I can make the table foo use foo_seq one of two ways:</div>
<div>
<br>
</div>
<div>&nbsp;1. &nbsp;I can define a trigger that will automatically get a value from foo_seq every time a row is inserted</div>
<div>&nbsp;2. &nbsp;I can write the INSERT query like this:</div>
<div><br></div>
<div>&nbsp;&nbsp; &nbsp;INSERT INTO foo(foo_pk) VALUES (foo_seq.nextval);</div>
<div><br></div>
<div>Of course, Storm has a way of compiling sequences. &nbsp;But unless I'm missing something, the only real way to take advantage of that would be something like this:</div>
<div><br></div>
<div><br></div>
<div>
&nbsp;&nbsp; &nbsp;foo_row = Foo()</div>
<div>&nbsp;&nbsp; &nbsp;if db_platform == 'oracle':</div>
<div>&nbsp;&nbsp; &nbsp; &nbsp; &nbsp;foo_row.foo_pk = Sequence('foo_seq')</div>
<div>&nbsp;&nbsp; &nbsp;store.add(foo_row)</div>
<div><br></div>
<div>But it would be nice to have a way of defining a column that will get its value from a particular sequence automatically.</div>
<div><br></div>
<div>Another idea that just occurred to me is that most of the time, sequences will be defined by giving the table name plus some kind of suffix like "_seq". &nbsp;So it would save a *lot* of tedium if I could do something like this:</div>
<div><br></div>
<div>SequenceProperty = sequencemaker(suffix='_seq')</div>
<div><br></div>
<div>class Foo(object):</div>
<div>&nbsp;&nbsp; &nbsp;__storm_table__ = 'foo'</div>
<div><br></div>
<div>&nbsp;&nbsp; &nbsp;# assume the sequence will be named 'foo_seq' since the table is named foo</div>
<div>&nbsp;&nbsp; &nbsp;foo_pk = SequenceProperty(primary=True, datatype=Int)</div>
<div><br></div>
<div>And have backends like MySQL, SQL Server, and SQLite ignore the fact that it's a Sequence property</div>
</div></div>
James Henstridge | 6 Dec 2009 07:06
Picon
Gravatar

Re: New lp:~storm/storm/packaging branch

On Sat, Dec 5, 2009 at 12:05 AM, Jamu Kakar <jkakar@...> wrote:
> Hi Jason,
>
> On Fri, Dec 4, 2009 at 6:33 AM, Jason Baker <jbaker@...> wrote:
>> Just out of sheer curiosity, what is the purpose of this change?  What
>> advantages are there to doing things that way?
>
> The primary purpose of the change, at least the reason I made it, is
> to keep the mainline history clean.  I use AutoPPA to build packages
> and if you look back in the history you'll see fair amount of noise
> created as a result of AutoPPA merging changes made to produce a
> build back into trunk.  Using a separate packaging branch alleviates
> this and keeps trunk a pure upstream branch.  It's a pattern that
> subunit uses, and I think Bazaar too.
>
> I've been told by real packagers (I'm mostly a faker) that this kind
> of separation is preferred because it's somehow easier for them to
> make changes.  I don't fully understand why this is, to be honest.

What most of the Debian/Ubuntu packagers don't like is upstream
tarballs that contain a debian directory.  Since the debian source
packages are made up of a pristine source tarball and a diff, having a
debian directory in the tarball introduces the possibility of
conflicts when updating to a new version.

James.

--

-- 
storm mailing list
storm@...
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/storm

James Henstridge | 6 Dec 2009 07:21
Picon
Gravatar

Re: Oracle sequence columns

On Sun, Dec 6, 2009 at 12:38 AM, Jason Baker <jbaker@...> wrote:
> On Fri, Dec 4, 2009 at 5:31 PM, Jamu Kakar <jkakar@...> wrote:
>>
>> Hi Jason,
>>
>> On Fri, Dec 4, 2009 at 2:43 PM, Jason Baker <jbaker@...> wrote:
>> > One thing we'd like to have in storm is the ability to specify a
>> > sequence
>> > that we can use by default on primary keys.  For instance, suppose I
>> > have a
>> > class like this:
>> >     class Foo(object):
>> >         __storm_table__ = 'foo'
>> >         foo_pk = Int(primary=True)
>> > If we want foo_pk to autoincrement on Oracle, our only option is to
>> > define a
>> > trigger that will call nextval on the sequence.  It would be nice to be
>> > able
>> > to do something like this:
>> >     class Foo(object):
>> >         __storm_table__ = 'foo'
>> >         foo_pk = Int(primary=True, sequence_name='foo_seq')
>> > This way, when I insert a new Foo, it will automatically pull from
>> > foo_seq
>> > and I don't have to define a trigger.  Of course for this to be useful,
>> > other platforms would need to ignore that keyword argument.  I'd be
>> > willing
>> > to work on this if someone could give me some feedback into the best way
>> > to
>> > implement this.
>>
>> I don't really understand how Oracle works
>
> One thing that's important to understand is that Oracle doesn't have any way
> to define an IDENTITY/AUTOINCREMENT field.  You may or may not already know
> this, I just thought it would be good to mention it in case you didn't.  :-)
>
>>
>>  In other words,
>> do you need Storm to issue a particular query whenever you perform
>> an insert to get autoincrement behaviour or do you just need to
>> define a trigger as part of your schema?
>
>
> In Oracle circles, a trigger is considered to be a hacky workaround for
> applications that aren't able to work with sequences.  Here's how it would
> work.  Suppose I define a table and sequence like this:
>     CREATE TABLE foo(
>     foo_pk INT PRIMARY KEY);
>     CREATE SEQUENCE foo_seq;
> I can make the table foo use foo_seq one of two ways:
>  1.  I can define a trigger that will automatically get a value from foo_seq
> every time a row is inserted
>  2.  I can write the INSERT query like this:
>     INSERT INTO foo(foo_pk) VALUES (foo_seq.nextval);

PostgreSQL also works in terms of sequences as well.  When you create
a table with:

  CREATE TABLE foo (foo_pk SERIAL PRIMARY KEY);

It is actually short hand for something like:

   CREATE SEQUENCE foo_foo_pk_seq;
   CREATE TABLE foo (foo_pk INT NOT NULL DEFAULT
nextval('foo_foo_pk_seq') PRIMARY KEY);

As the default value pulls from the sequence, if you don't specify the
column in the INSERT query, it automatically gets the sequence value.
Is something like this possible with Oracle?

> Of course, Storm has a way of compiling sequences.  But unless I'm missing
> something, the only real way to take advantage of that would be something
> like this:
>
>     foo_row = Foo()
>     if db_platform == 'oracle':
>         foo_row.foo_pk = Sequence('foo_seq')
>     store.add(foo_row)
> But it would be nice to have a way of defining a column that will get its
> value from a particular sequence automatically.
> Another idea that just occurred to me is that most of the time, sequences
> will be defined by giving the table name plus some kind of suffix like
> "_seq".  So it would save a *lot* of tedium if I could do something like
> this:
> SequenceProperty = sequencemaker(suffix='_seq')
> class Foo(object):
>     __storm_table__ = 'foo'
>     # assume the sequence will be named 'foo_seq' since the table is named
> foo
>     foo_pk = SequenceProperty(primary=True, datatype=Int)
> And have backends like MySQL, SQL Server, and SQLite ignore the fact that
> it's a Sequence property

Well, if you are writing an application for Oracle, you could always
do something like this:

class Foo(object):
    __storm_table__ = 'foo'
    foo_pk = Int(primary=True, default=Nextval('foo_seq'))

Where Nextval is an expression class that compiles to the right
syntax.  If you've got access to an "INSERT ... RETURNING ..." style
statement to retrieve the allocated primary key, then that might be
enough.

James.

--

-- 
storm mailing list
storm@...
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/storm


Gmane