James Henstridge | 2 Jul 18:01 2010
Picon

Update branch format for trunk?

Currently the Storm trunk is stored in the old pack-0.92 format that
dates back to the Bazaar 1.0 release.  We've got a few branches
tracking storm stored in the newer "2a" format (made default in Bazaar
2.0), and I was wondering if anyone would object to changing the trunk
to the newer format.

My main reason for asking this is that changes can only be moved in
one direction between these formats (i.e. we can pull pack-0.92
changes, but nothing can go in the other direction).  So moving the
trunk forward would reduce the chance that I'd need to redo commits in
order to create a mergeable branch.

It would also have some direct benefits, since Launchpad can handle
the newer branches better by stacking them on the trunk branch..  In
other words, uploading a new branch will only upload the changes you
made rather than Storm's entire history (which is currently ~ 3.5MB).

The obvious down side is that if we upgrade the trunk, everyone else
will need to upgrade their branches if they want to pull new changes
from trunk.  They will also need to make sure they have Bazaar 2.0 or
later.

So what do others think?

James.

Jamu Kakar | 2 Jul 18:18 2010
Picon

Re: Update branch format for trunk?

Hi,

On Fri, Jul 2, 2010 at 6:01 PM, James Henstridge <james <at> jamesh.id.au> wrote:
> Currently the Storm trunk is stored in the old pack-0.92 format that
> dates back to the Bazaar 1.0 release.  We've got a few branches
> tracking storm stored in the newer "2a" format (made default in Bazaar
> 2.0), and I was wondering if anyone would object to changing the trunk
> to the newer format.
>
> My main reason for asking this is that changes can only be moved in
> one direction between these formats (i.e. we can pull pack-0.92
> changes, but nothing can go in the other direction).  So moving the
> trunk forward would reduce the chance that I'd need to redo commits in
> order to create a mergeable branch.
>
> It would also have some direct benefits, since Launchpad can handle
> the newer branches better by stacking them on the trunk branch..  In
> other words, uploading a new branch will only upload the changes you
> made rather than Storm's entire history (which is currently ~ 3.5MB).
>
> The obvious down side is that if we upgrade the trunk, everyone else
> will need to upgrade their branches if they want to pull new changes
> from trunk.  They will also need to make sure they have Bazaar 2.0 or
> later.
>
> So what do others think?

+1 from me.  Note that we have an open RT with Canonical's
operations staff to have all Storm branches upgraded.

(Continue reading)

Jamu Kakar | 5 Jul 18:03 2010
Picon

Re: Update branch format for trunk?

Hi,

On Fri, Jul 2, 2010 at 6:18 PM, Jamu Kakar <jkakar <at> kakar.ca> wrote:
> Hi,
>
> On Fri, Jul 2, 2010 at 6:01 PM, James Henstridge <james <at> jamesh.id.au> wrote:
>> Currently the Storm trunk is stored in the old pack-0.92 format that
>> dates back to the Bazaar 1.0 release.  We've got a few branches
>> tracking storm stored in the newer "2a" format (made default in Bazaar
>> 2.0), and I was wondering if anyone would object to changing the trunk
>> to the newer format.
>>
>> My main reason for asking this is that changes can only be moved in
>> one direction between these formats (i.e. we can pull pack-0.92
>> changes, but nothing can go in the other direction).  So moving the
>> trunk forward would reduce the chance that I'd need to redo commits in
>> order to create a mergeable branch.
>>
>> It would also have some direct benefits, since Launchpad can handle
>> the newer branches better by stacking them on the trunk branch..  In
>> other words, uploading a new branch will only upload the changes you
>> made rather than Storm's entire history (which is currently ~ 3.5MB).
>>
>> The obvious down side is that if we upgrade the trunk, everyone else
>> will need to upgrade their branches if they want to pull new changes
>> from trunk.  They will also need to make sure they have Bazaar 2.0 or
>> later.
>>
>> So what do others think?
>
(Continue reading)

Andrew Bennetts | 6 Jul 08:43 2010

Re: Update branch format for trunk?

Jamu Kakar wrote:
[...]
> You can upgrade your own branches with:
> 
> bzr upgrade lp:~<username>/storm/≤branch>

You should also be able to do it by clicking the “Upgrade this branch”
link on the Launchpad page for your branch
(https://code.launchpad.net/~<username>/storm/≤branch>).

-Andrew.

--

-- 
storm mailing list
storm <at> lists.canonical.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/storm
Eduardo Willians | 17 Jul 18:33 2010
Picon

how to refresh store.find( )

Well, this may look stupid, but here is.

I do:

number = store.find(Broker).max(Broker.number)

I get the number. But if another db connection adds a new row to DB,
and the code is run again:

number = store.find(Broker).max(Broker.number)

I get the SAME number instead of the new one was just added, because
storm's cache was not updated (I think).

There at least two solutions:

First:
store.commit()
number = store.find(Op).max(Op.number)
This is very dangerous because if there's any pending transaction it
will be committed to DB, so I can't use this.

Second:
store.rollback()
number = store.find(Op).max(Op.number)
This one is also dangerous, because if there's any pending transcation
waiting to be commited it will go away.

invalidate() and flush() does not work. And I think reset() is not recommended.

(Continue reading)

Jamu Kakar | 17 Jul 18:44 2010
Picon

Re: how to refresh store.find( )

Hi,

On Sat, Jul 17, 2010 at 6:33 PM, Eduardo Willians
<edujurista@...> wrote:
> Well, this may look stupid, but here is.
>
> I do:
>
> number = store.find(Broker).max(Broker.number)
>
> I get the number. But if another db connection adds a new row to DB,
> and the code is run again:
>
> number = store.find(Broker).max(Broker.number)
>
> I get the SAME number instead of the new one was just added, because
> storm's cache was not updated (I think).

Yes, this is expected because storm uses serializable transactions
(which means each transaction has a view of the database that is
based on a snapshot made when the transaction started).

> There at least two solutions:
>
> First:
> store.commit()
> number = store.find(Op).max(Op.number)
> This is very dangerous because if there's any pending transaction it
> will be committed to DB, so I can't use this.
>
(Continue reading)

Eduardo Willians | 17 Jul 20:42 2010
Picon

Re: how to refresh store.find( )

J.,

> 1. The way you described, use store.rollback.  If there are other
>   changes that you don't want to rollback then you may need to
>   rethink how your separating work among transactions.

That was I've suspected. But it's iteresting any one has ever talked
about that on this list, neither I've found on google.

from brazil.campo_grande import ThankYou

Eduardo Willians

--

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

Mac Ryan | 28 Jul 14:48 2010
Picon

Storm and Python 3.x series.

Hi,

	apologies for making such a basic question, but I looked at the online
documentation and could not find any information on this (I am sure it
must be there somewhere, but...).

	I would simply like to know if Storm can be used within programs using
the Python 3.x syntax, or if it only works with Python 2.x.

	Regards,
	Mac.

Jamu Kakar | 28 Jul 15:41 2010
Picon

Re: Storm and Python 3.x series.

Hi Mac,

On Wed, Jul 28, 2010 at 1:48 PM, Mac Ryan <quasipedia <at> gmail.com> wrote:
>        apologies for making such a basic question, but I looked at the online
> documentation and could not find any information on this (I am sure it
> must be there somewhere, but...).
>
>        I would simply like to know if Storm can be used within programs using
> the Python 3.x syntax, or if it only works with Python 2.x.

Right now Storm is only supported with Python 2.x (starting at 2.4).
Python 3.x support isn't really on our roadmap, because there hasn't
been any demand for it (and last I checked the DBAPI drivers were
still being ported).

Thanks,
J.

--

-- 
storm mailing list
storm <at> lists.canonical.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/storm
Vernon Cole | 28 Jul 17:49 2010
Picon

Re: Storm and Python 3.x series.

So, if I offer patches to use adodbapi for the now-supported database engines (as an option to than the "native" dbapi for each one) would those patches be considered?

The advantages:
1) Microsoft SQL Server databases could also be supported.
2) No need to install/import multiple api packages in order to read multiple db engines.
3) Storm could be ported to Python 3.
4) Storm could be ported to IronPython.

The disadvantages:
1) The code for each engine's front end would be a bit more complex (need to try adodbapi if the preferred import fails.)
2) Adodbapi does not work on Linux -- yet.

Followup question:
  If I make adodbapi run on Linux (would require IronPython and Mono) would you be more likely to accept the patches?
--
Vernon Cole


On Wed, Jul 28, 2010 at 7:41 AM, Jamu Kakar <jkakar-kvr/BIsI4Rg@public.gmane.org> wrote:
Hi Mac,

On Wed, Jul 28, 2010 at 1:48 PM, Mac Ryan <quasipedia-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>        apologies for making such a basic question, but I looked at the online
> documentation and could not find any information on this (I am sure it
> must be there somewhere, but...).
>
>        I would simply like to know if Storm can be used within programs using
> the Python 3.x syntax, or if it only works with Python 2.x.

Right now Storm is only supported with Python 2.x (starting at 2.4).
Python 3.x support isn't really on our roadmap, because there hasn't
been any demand for it (and last I checked the DBAPI drivers were
still being ported).

Thanks,

<div>
<p>So, if I offer patches to use adodbapi for the now-supported database engines (as an option to than the "native" dbapi for each one) would those patches be considered?<br><br>The advantages: <br>1) Microsoft SQL Server databases could also be supported.<br>

2) No need to install/import multiple api packages in order to read multiple db engines.<br>3) Storm could be ported to Python 3.<br>4) Storm could be ported to IronPython.<br><br>The disadvantages:<br>1) The code for each engine's front end would be a bit more complex (need to try adodbapi if the preferred import fails.)<br>

2) Adodbapi does not work on Linux -- yet.<br><br>Followup question:<br>&nbsp; If I make adodbapi run on Linux (would require IronPython and Mono) would you be more likely to accept the patches?<br>--<br>Vernon Cole<br><br><br></p>
<div class="gmail_quote">On Wed, Jul 28, 2010 at 7:41 AM, Jamu Kakar <span dir="ltr">&lt;<a href="mailto:jkakar@...">jkakar@...</a>&gt;</span> wrote:<br><blockquote class="gmail_quote">

Hi Mac,<br><div class="im">
<br>
On Wed, Jul 28, 2010 at 1:48 PM, Mac Ryan &lt;<a href="mailto:quasipedia <at> gmail.com">quasipedia@...</a>&gt; wrote:<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp;apologies for making such a basic question, but I looked at the online<br>
&gt; documentation and could not find any information on this (I am sure it<br>
&gt; must be there somewhere, but...).<br>
&gt;<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp;I would simply like to know if Storm can be used within programs using<br>
&gt; the Python 3.x syntax, or if it only works with Python 2.x.<br><br>
</div>Right now Storm is only supported with Python 2.x (starting at 2.4).<br>
Python 3.x support isn't really on our roadmap, because there hasn't<br>
been any demand for it (and last I checked the DBAPI drivers were<br>
still being ported).<br><br>
Thanks,<br><div>
<div></div>
<div class="h5">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>
</div>
</div>
</blockquote>
</div>
<br>
</div>

Gmane