Hello,
  Seems that 2.04 b4 is the most stable build in EDB History
  with over 2 months without a new build!

  Great Job Tim!

--
Charalampos Michael - [Creation Power] - http://www.creationpower.gr

or TIM.... working on another project ?

Or fixing a very hairy bug, .
I'm kidding, of course, there is no 'hairy' bug that I know of
I'd bet Tim is cooking some new nice features for us

Fernando Dias
[Team Elevate]



Em 06-12-2010 10:08, Charalampos Michael escreveu:
> Hello,
> Seems that 2.04 b4 is the most stable build in EDB History
> with over 2 months without a new build!
>
> Great Job Tim!
>

Dear Fernando,

>
> Or fixing a very hairy bug, .
> I'm kidding, of course, there is no 'hairy' bug that I know of
> I'd bet Tim is cooking some new nice features for us
>
> Fernando Dias
> [Team Elevate]

Let me smell ... Snif Snif ... I'm smelling EDB 3.0!!! Right ?

--
Charalampos Michael - [Creation Power] - http://www.creationpower.gr

Michael,

<< Seems that 2.04 b4 is the most stable build in EDB History with over 2
months without a new build! >>

Well, part of that is due to an issue that caused me to "change course
mid-stream" when getting ready to do a new 2.04 build.  First there was an
issue with a particular server call that will require a new minor release
(2.05).  Once that was found, I decided to go ahead with some new
replication features in 2.05, and that has also resulted in finding a design
flaw in the replication update loading that required a fix.  This one was a
bit more complicated, but basically the general problem was that you could
cause a load failure with a setup like this:

Master Table
Detail Table with FK pointing to Master Table ID

Sequence   Operation
======================================
(1)             Add new master row #1
(2)             Add new master row #2
(3)             Add new detail row that points to master row #1
(4)             Update this detail row so that it now points to master row
#2
(5)             Delete master row #1

Currently, the updates are loaded from an update file in table dependency
order, meaning that all of the updates will be loaded for the Master, and
then all of the updates will be loaded for the Detail.  This, of course,
won't work with the above sequence, because the detail row insert that
refers to master row #1 will occur *after* the master row #1 is deleted.
So, I had to put on my design hat and spend about 3 weeks coming up with a
design that can accommodate the above scenario using the existing formats.
The reason that the updates are logged per-table is that I didn't want
updates to have to go into a database-wide update file in real-time, nor did
I want them to have to retrieve a transaction counter from a common
location, in order to allow for better concurrency.  Putting all updates
into the same file is like trying to pour several gallons of water from
different receptacles into the same funnel at the same time.

A couple of days ago I finally came up with a solution that works without
any format changes and allows for proper sequencing of operations while
still maintaining the same level of concurrency.  This has been the hold-up
for 2.05, so I can finally wrap it up and get it out the door.

--
Tim Young
Elevate Software
www.elevatesoft.com

Mauro,

<< or TIM.... working on another project ? >>

The only other project that I'm working on is the Enterprise version of the
ElevateDB Server.  I *did* take a little bit of a break in October, per my
blog post here:

http://www.elevatesoft.com/blog?action=view&id=casual_friday_for_week_ending_november_12th

but I've been working on a sticky replication issue over the last month (see
my post in this thread).

--
Tim Young
Elevate Software
www.elevatesoft.com

Dear Tim,

> A couple of days ago I finally came up with a solution that works
> without any format changes and allows for proper sequencing of
> operations while still maintaining the same level of concurrency. This
> has been the hold-up for 2.05, so I can finally wrap it up and get it
> out the door.

OMG, that was hard ...

--
Charalampos Michael - [Creation Power] - http://www.creationpower.gr

How is replication for 2.03b23?  I'm about to roll out a re-issued
replication version of a small application and have been waiting to update
to 2.04 or greater because the version I'm on seems quite stable.  Is the
issue you detail below a design-issue for all versions?  Or only the new one
you're working on?

David Cornelius
Cornelius Concepts

"Tim Young [Elevate Software]"  wrote in message
news:89B65C50-9C0E-4BE9-ADD8-4BF803AC6B95@news.elevatesoft.com...

Michael,

<< Seems that 2.04 b4 is the most stable build in EDB History with over 2
months without a new build! >>

Well, part of that is due to an issue that caused me to "change course
mid-stream" when getting ready to do a new 2.04 build.  First there was an
issue with a particular server call that will require a new minor release
(2.05).  Once that was found, I decided to go ahead with some new
replication features in 2.05, and that has also resulted in finding a design
flaw in the replication update loading that required a fix.  This one was a
bit more complicated, but basically the general problem was that you could
cause a load failure with a setup like this:

Master Table
Detail Table with FK pointing to Master Table ID

Sequence   Operation
======================================
(1)             Add new master row #1
(2)             Add new master row #2
(3)             Add new detail row that points to master row #1
(4)             Update this detail row so that it now points to master row
#2
(5)             Delete master row #1

Currently, the updates are loaded from an update file in table dependency
order, meaning that all of the updates will be loaded for the Master, and
then all of the updates will be loaded for the Detail.  This, of course,
won't work with the above sequence, because the detail row insert that
refers to master row #1 will occur *after* the master row #1 is deleted.
So, I had to put on my design hat and spend about 3 weeks coming up with a
design that can accommodate the above scenario using the existing formats.
The reason that the updates are logged per-table is that I didn't want
updates to have to go into a database-wide update file in real-time, nor did
I want them to have to retrieve a transaction counter from a common
location, in order to allow for better concurrency.  Putting all updates
into the same file is like trying to pour several gallons of water from
different receptacles into the same funnel at the same time.

A couple of days ago I finally came up with a solution that works without
any format changes and allows for proper sequencing of operations while
still maintaining the same level of concurrency.  This has been the hold-up
for 2.05, so I can finally wrap it up and get it out the door.

--
Tim Young
Elevate Software
www.elevatesoft.com

David,

<< How is replication for 2.03b23?  I'm about to roll out a re-issued
replication version of a small application and have been waiting to update
to 2.04 or greater because the version I'm on seems quite stable.  Is the
issue you detail below a design-issue for all versions?  Or only the new one
you're working on? >>

It's a design issue for all versions of 2.x since the replication was
introduced.  However, it only affects databases where primary keys are
modified/deleted, and there are FKs that refer to these primary keys.  So,
if your database does not fit those criteria, then it won't be affected.

--
Tim Young
Elevate Software
www.elevatesoft.com