>>>>> On 27 Oct 2001 19:05:02 +0400, Ilya Martynov <ilya@...> said:
>>>>> On Wed, 24 Oct 2001 15:35:29 -0500 (CDT), Dave Rolsky <autarch@...> said:
DR> If you think of a way to use the Storable hooks I'll gladly do so, but I
DR> don't think its possible.
IM> Here the proof :)
Some notes about this patch. Currenly there are no tests where object
is serialized in one process and restored in anythere. But it seems to
work. In my web project I put potential row objects into session
object (Apache::Session) so they get serialized by Storable and later
they restore correctly.
As intresting side-effect row objects could be cloned now. However I
don't know if there exist any use for it.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
| Ilya Martynov (http://martynov.org/) TIV.net (http://tiv.net/) |
| GnuPG 1024D/323BDEE6 D7F7 561E 4C1D 8A15 8E80 E4AE BE1A 53EB 323B DEE6 |
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

On Fri, 26 Oct 2001, Rob McMillin wrote:
> Has anyone attempted to make Alzabo work with Oracle?
Someone started working on this a while back and gave me the code he had
produced up that point. I'd estimate its maybe 1/3-1/2 done. Its in the
CVS tree.
The biggest bits left undone are setting up the Oracle database
functions to be exported in SQLMaker/Oracle.pm and going through the rules
to make sure they're corrected (they're based on altered versions of the
Postgres rules) and tweaking them for Oracle. Also, reverse engineering
needs to be done as well.
I haven't gotten around to this cause I still haven't gotten around to
installing Oracle on any machine I could develop on.
-dave
/*==================
http://www.urth.org
We await the New Sun
==================*/

On 24 Oct 2001, Ilya Martynov wrote:
> DR> Maybe I could make this an option to Alzabo::MethodMaker.
>
> It makes sense. I don't know but maybe for some databases starting
> transaction adds some overheat.
Its not so much that as adding yet another method. It probably doesn't
matter given all the other crap Alzabo wraps around DBI anyway. People
aren't using Alzabo cause its fast ;)
> I've played with Tangram a little. It is nice thing but I dropped it
> in favor of Alzabo because:
>
> 1) With Alzabo it is very easy to upgrade data schemas. Database
> schema diffs rules :) Last time I've checked Tangram it could only
> make initial deployment.
I know he plans to implement that eventually.
> 3) I just like Alzabo's API more than Tangram's :)
Yeah, I'm not too fond of Tangram's API either. It never clicked for me.
-dave
/*==================
http://www.urth.org
We await the New Sun
==================*/

On 24 Oct 2001, Ilya Martynov wrote:
> Just checked new POD docs. You wrote:
>
> To serialize a row object requires some extra work. Simply
> passing an object to C<Data::Dumper> or C<Storable> is definitely
> B<not> recommended.
>
> Funny thing is that I want serizalization via Storable to be
> *recomended* way :)
If you think of a way to use the Storable hooks I'll gladly do so, but I
don't think its possible.
-dave
/*==================
http://www.urth.org
We await the New Sun
==================*/

>>>>> On Wed, 24 Oct 2001 12:28:50 -0500 (CDT), Dave Rolsky <autarch@...> said:
>> IMHO It is nice to be sure that update, select, etc are always atomic
>> irrelevant what user have put into theirs hooks.
DR> Yes, but _most_ people probably won't need this.
DR> Maybe I could make this an option to Alzabo::MethodMaker.
It makes sense. I don't know but maybe for some databases starting
transaction adds some overheat.
>> With introduction of hooks I've tried to move this code into them but
>> I quickly found that if I put database code into update_hook it is no
>> longer atomic. And as I said before there is no easy way to just
>> override update method.
>>
>> Uhh, it started with hooks and finished with completely another issue
>> :) Dave, what do you it think about this task? Is there any better way
>> to map two classes with common functionality into database using
>> Alzabo?
DR> I've thought in the past about trying to add some OODBMS features to
DR> Alzabo. However, that seems a little silly since for people who really
DR> want that there's already Tangram (www.tangram-persistence.org) which is a
DR> mature and useful tool.
I've played with Tangram a little. It is nice thing but I dropped it
in favor of Alzabo because:
1) With Alzabo it is very easy to upgrade data schemas. Database
schema diffs rules :) Last time I've checked Tangram it could only
make initial deployment.
2) Latest versions of Tangram have more restrictive license. It is GPL
only.
3) I just like Alzabo's API more than Tangram's :)
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
| Ilya Martynov (http://martynov.org/) TIV.net (http://tiv.net/) |
| GnuPG 1024D/323BDEE6 D7F7 561E 4C1D 8A15 8E80 E4AE BE1A 53EB 323B DEE6 |
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

>>>>> On Wed, 24 Oct 2001 12:24:26 -0500 (CDT), Dave Rolsky <autarch@...> said:
DR> The only issue I can think of is that regular rows assume that when they
DR> are being thawed they are already in the object cache (if caching is being
DR> used).
DR> If you were to freeze an object, clear the cache, and then unfreeze it,
DR> that would be problematic. The object would be effectively locked out of
DR> the syncing system at that point. What needs to happen is that the thawed
DR> object needs to ensure that it is present in the syncing system. I'm not
DR> sure how to do that though. Calling ->register_store is the only way that
DR> currently exists to add a new object in, but to do that we have to have
DR> the time that the object was last updated, which is stored in the caching
DR> system, not the object.
DR> I just wrote the code to deal with this and documented freeze and thaw as
DR> public methods.
DR> If you want to send me code to do this for PotentialRow, that'd be great.
With latest CVS should you just remove
Alzabo::Runtime::PotentialRow::freeze and
Alzabo::Runtime::PotentialRow::thaw and it works :)
However I don't like current serialization API. I thought about
serialization implementation transparent to Storable. So following
code works as expected:
use Storable qw(freeze);
my $ser = freeze $row1;
....
....
use Storable qw(thaw);
my $row2 = thaw $ser;
it seems to be possible since Storable provides some hooks for objects
which wish to change algorithm of serialization.
I like it more that current
my $ser = $row1->freeze;
....
....
my $row2 = Alzabo::Runtime::Row->thaw($ser);
because we don't need to hardcode package name anymore
(Alzabo::Runtime::Row) and it allows to use transparently any
persistence frameworks based on Storable (like Apache::Session). For
example we can just write
$session{row} = $row;
....
....
$row = $session{row};
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
| Ilya Martynov (http://martynov.org/) TIV.net (http://tiv.net/) |
| GnuPG 1024D/323BDEE6 D7F7 561E 4C1D 8A15 8E80 E4AE BE1A 53EB 323B DEE6 |
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

On 24 Oct 2001, Ilya Martynov wrote:
> I've not investigated code too much but it seems that problem with
> scalar/list context exists only for select hook?
Yes.
> IMHO It is nice to be sure that update, select, etc are always atomic
> irrelevant what user have put into theirs hooks.
Yes, but _most_ people probably won't need this.
Maybe I could make this an option to Alzabo::MethodMaker.
> With introduction of hooks I've tried to move this code into them but
> I quickly found that if I put database code into update_hook it is no
> longer atomic. And as I said before there is no easy way to just
> override update method.
>
> Uhh, it started with hooks and finished with completely another issue
> :) Dave, what do you it think about this task? Is there any better way
> to map two classes with common functionality into database using
> Alzabo?
I've thought in the past about trying to add some OODBMS features to
Alzabo. However, that seems a little silly since for people who really
want that there's already Tangram (www.tangram-persistence.org) which is a
mature and useful tool.
I don't know that there's a good way to do OODBMS stuff with Alzabo.
RDBMS's by nature are not designed for this. Mapping one onto the other
is a huge problem, and is the one that Tangram solves (among other
problems).
> If no, maybe I should start writting patch for atomic hooks :)
That'd be great.
/*==================
http://www.urth.org
We await the New Sun
==================*/

On 24 Oct 2001, Ilya Martynov wrote:
> This pattern seems to be very usefull so I want to ask you if you will
> accept patch for its support.
Sure.
> Alzabo already has some support for row object serialization. Row
> object classes have methods freeze and thaw (and my existing hack is
> based on them). However in stock Alzabo it works only for normal row
> objects and only if ObjectCache is loaded.
>
> As I understand right now you use serizalition only in object caching
> code but at first look I don't see why Alzabo user's cannot use this
> functionality ourselves. Is there any caveats I've overlooked?
The only issue I can think of is that regular rows assume that when they
are being thawed they are already in the object cache (if caching is being
used).
If you were to freeze an object, clear the cache, and then unfreeze it,
that would be problematic. The object would be effectively locked out of
the syncing system at that point. What needs to happen is that the thawed
object needs to ensure that it is present in the syncing system. I'm not
sure how to do that though. Calling ->register_store is the only way that
currently exists to add a new object in, but to do that we have to have
the time that the object was last updated, which is stored in the caching
system, not the object.
I just wrote the code to deal with this and documented freeze and thaw as
public methods.
If you want to send me code to do this for PotentialRow, that'd be great.
-dave
/*==================
http://www.urth.org
We await the New Sun
==================*/

Dave,
I've been played with potential row staff and I found that I want them
to be serializable.
For example one web project under which I work right now has some
messaging service. Registered users of web site can send each other
variuos messages.
Before user comes to message edition and preview screens I create
potential message object and store it (I've hacked Alzabo slightly so
it allows me to do it) into session object (Apache::Session). During
message edition user can switch many times between edit and preview
screens all changes to message are stored in session.
Once person finished with message edition message object goes live
($message->make_live).
This pattern seems to be very usefull so I want to ask you if you will
accept patch for its support.
Alzabo already has some support for row object serialization. Row
object classes have methods freeze and thaw (and my existing hack is
based on them). However in stock Alzabo it works only for normal row
objects and only if ObjectCache is loaded.
As I understand right now you use serizalition only in object caching
code but at first look I don't see why Alzabo user's cannot use this
functionality ourselves. Is there any caveats I've overlooked?
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
| Ilya Martynov (http://martynov.org/) TIV.net (http://tiv.net/) |
| GnuPG 1024D/323BDEE6 D7F7 561E 4C1D 8A15 8E80 E4AE BE1A 53EB 323B DEE6 |
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

>>>>> On Mon, 22 Oct 2001 16:15:42 -0500 (CDT), Dave Rolsky <autarch@...> said:
DR> On 22 Oct 2001, Ilya Martynov wrote:
>> I discovered a problem with implementation of these hooks in
>> MethodMaker. Since code inside hooks can perform some database
>> operation itself calls to corresponding methods (update, select,
>> insert and delete) are no longer atomic.
>>
>> It seems that MethodMaker should wrap generated code in call of
>> $schema->run_in_transaction to ensure that it runs inside single
>> transaction.
DR> So I started on this and realizes its somewhat of a can of worms. If I
DR> wrap everything in ->run_in_transaction then it gets kind of tricky to
DR> preserve scalar/list context.
DR> I think maybe it should up to the user to decide to wrap their various
DR> update, insert, calls in ->run_in_transaction. In the common case, I
DR> expect that the hooks will be used as data filters and validators and
DR> won't be inserting/updating/or deleting from the DB. In the other cases,
DR> then you know well enough to wrap your own calls.
I've not investigated code too much but it seems that problem with
scalar/list context exists only for select hook?
IMHO It is nice to be sure that update, select, etc are always atomic
irrelevant what user have put into theirs hooks.
Anyway I recenlty found one application for hooks other than data
filters and validators.
I'm not sure I've choosen correct solution for my task but let me
describe task first.
I have two 'classes' of objects that have something common. Good OOD
tells us that we should have three classes: one base abstract which
implements common functionality and two its child classes.
And I want instances of these classes to be persistent. On database
level it means that (one variant) we have three tables - one for
columns which are common to all classes and two tables for class
specific data. So data for each object is always spread across two
tables.
How can I map my classes to database preserving these design decisions
using Alzabo and MethodMaker?
My first naive and ugly attempt:
I have three row classes for each table. Row class which corresponds
to 'common columns' table has AUTOLOAD which proxies unknown method
calls to corresponding row class in second table. Also I have
customized update method.
sub update_all {
my $self = shift;
my %data = @_;
my %column_names = map +($_->name => 1), $self->table->columns;
my @our_cols = grep $column_names{$_}, keys %data;
my %our_data = ();
@our_data{@our_cols} = delete @data{@our_cols};
my $schema = $self->table->schema;
$schema->run_in_transaction(sub {
$self->update(%our_data);
$self->linked->update(%data);
});
}
Note that it is hard to override 'update' method call because
$self->SUPER::update do not have any sense for row classes.
Clearly it is not very good design - I don't have one base abstract
class and two 'real' classes. Instead I have one class which
selectively proxies methods to one of 'real' classes. But at least on
API level it looks ok.
With introduction of hooks I've tried to move this code into them but
I quickly found that if I put database code into update_hook it is no
longer atomic. And as I said before there is no easy way to just
override update method.
Uhh, it started with hooks and finished with completely another issue
:) Dave, what do you it think about this task? Is there any better way
to map two classes with common functionality into database using
Alzabo?
If no, maybe I should start writting patch for atomic hooks :)
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
| Ilya Martynov (http://martynov.org/) TIV.net (http://tiv.net/) |
| GnuPG 1024D/323BDEE6 D7F7 561E 4C1D 8A15 8E80 E4AE BE1A 53EB 323B DEE6 |
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

>>>>> On Tue, 23 Oct 2001 16:19:25 -0500 (CDT), Dave Rolsky <autarch@...> said:
DR> Thanks. This will be part of 0.59 (probably out soon).
DR> In the future, can you send unified diffs (diff -u)? I think you have in
DR> the past. The other ones are really hard to eyeball.
Sorry. It was too late for me and I was too sleepy when I've made a
patch :)
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
| Ilya Martynov (http://martynov.org/) TIV.net (http://tiv.net/) |
| GnuPG 1024D/323BDEE6 D7F7 561E 4C1D 8A15 8E80 E4AE BE1A 53EB 323B DEE6 |
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

On 24 Oct 2001, Ilya Martynov wrote:
> I've notice a bug in Alzabo::Runtime::PotentialRow::new. It doesn't
> handle correctly parameter 'values'.
>
> Here patch with fix and test case.
Thanks. This will be part of 0.59 (probably out soon).
In the future, can you send unified diffs (diff -u)? I think you have in
the past. The other ones are really hard to eyeball.
-dave
/*==================
http://www.urth.org
We await the New Sun
==================*/

On 22 Oct 2001, Ilya Martynov wrote:
> I discovered a problem with implementation of these hooks in
> MethodMaker. Since code inside hooks can perform some database
> operation itself calls to corresponding methods (update, select,
> insert and delete) are no longer atomic.
>
> It seems that MethodMaker should wrap generated code in call of
> $schema->run_in_transaction to ensure that it runs inside single
> transaction.
So I started on this and realizes its somewhat of a can of worms. If I
wrap everything in ->run_in_transaction then it gets kind of tricky to
preserve scalar/list context.
I think maybe it should up to the user to decide to wrap their various
update, insert, calls in ->run_in_transaction. In the common case, I
expect that the hooks will be used as data filters and validators and
won't be inserting/updating/or deleting from the DB. In the other cases,
then you know well enough to wrap your own calls.
-dave
/*==================
http://www.urth.org
We await the New Sun
==================*/

On 22 Oct 2001, Ilya Martynov wrote:
> I've noticed that my code often uses $row->table->schema
> construct. Maybe it is good idea to add method schema to row class so
> it will be possible to get schema object directly with just
> $row->schema? It doesn't break anything but saves some keypresses :)
Man, talk about laziness ;)
I never find myself needing this cause I always store the schema in some
global-ish way.
I'll add this, I guess.
-dave
/*==================
http://www.urth.org
We await the New Sun
==================*/

On 22 Oct 2001, Ilya Martynov wrote:
> I discovered a problem with implementation of these hooks in
> MethodMaker. Since code inside hooks can perform some database
> operation itself calls to corresponding methods (update, select,
> insert and delete) are no longer atomic.
>
> It seems that MethodMaker should wrap generated code in call of
> $schema->run_in_transaction to ensure that it runs inside single
> transaction.
Yeah, that seems reasonable. I'll add that for the next version.
-dave
/*==================
http://www.urth.org
We await the New Sun
==================*/

[cc'ing alzabo list in case anyone else has seen errors like this]
On Mon, 15 Oct 2001, Alexei Barantsev wrote:
> Exceptions of 'make test TEST_VERBOSE=1' output are following. Tests were
> performed for PostgreSQL-7.1.3 backend. I hope this information will be
> helpful. If not - what else should I tell you?
> t/02-create..........1..272
> not ok 125 - object->isa('Alzabo::Exception')
> # Failed test (t/base.pl at line 33)
> # The object isn't a 'Alzabo::Exception'
> # Looks like you failed 1 tests of 272.
> dubious
> Test returned status 1 (wstat 256, 0x100)
> DIED. FAILED test 125
> Failed 1/272 tests, 99.63% okay
That is very weird. It certainly shouldn't die there. There's a spot in
that file that looks like this:
eval { $t1->column('foo_pk')->set_type('text') };
my_isa_ok( $@, 'Alzabo::Exception',
"Attempting to set a primary key column to the 'text' type should throw an exception" );
if you could add this between the eval and the next line:
warn $@ if $@;
that might be helpful.
> t/03-runtime.........1..978
> DBD::Pg::db do failed: ERROR: CREATE DATABASE: source database "template1"
> is being accessed by other users at blib/lib
> /Alzabo/Driver/PostgreSQL.pm line 42.
> FAILED tests 671-978
> Failed 308/978 tests, 68.51% okay
This is some weird problem with the postgres daemon. When Alzabo tries to
create a Postgres database, it connects to the template1 DB and issues a
CREATE DATABASE SQL statement. I need to find a better way to do this, I
think.
> t/08-lru.............1..3
> DBD::Pg::db do failed: ERROR: CREATE DATABASE: database "test_alzabo_pg"
> already exists at blib/lib/Alzabo/Driver/Postg
> reSQL.pm line 42.
Try copying 06-db_drop.t to 08-db_drop.t and see if it works.
I suspect you'd be ok installing this version regardless but its always
good to get stuff fixed.
-dave
/*==================
http://www.urth.org
We await the New Sun
==================*/

>>>>> On Sat, 13 Oct 2001 15:24:27 -0500 (CDT), Dave Rolsky <autarch@...> said:
DR> I realized why I don't like that terminology. Attached things can
DR> generally be detached. BUt in this case once something it is attached it
DR> cannot ever be detached (though it can be deleted). I'm favoring the term
DR> live or actualized or something right now for the row after its in the DB.
DR> Now I just need a counterpart.
I understand.
According my dictionary:
actualized
adj : changed from potential to actual .....
^^^^^^^^^^^
Dunno if it is good idea but maybe than 'potential' row?
So we have
$table->potential_row
and
$row->actualize
DR> On yet another hand, I like the idea of catching errors as early as
DR> possible. I think I'll have it validate verything except referential
DR> integrity.
>> invented :) doesn't have to obey many strict checks for 'normal'
>> objects. It is an object in 'half-baked' state so Alzabo should not be
>> very strict with it.
DR> Well, I'm changing my mind again (and again and again).
I don't have strong opinion on this topic so it is ok for me.
DR> In other words, making a row live doesn't return a new row, it changes the
DR> state of the existing object. This means that everything that has a
DR> reference to it is still referring to the same thing. Fortunately, this
DR> is pretty easy in Perl.
I also thought about it. My usage patterns doen't really require it
but probably someone will find it useful.
How do you think to implement it? Create instance of 'normal' row object,
wipe all content of hashref of 'potential' object, copy content of
'normal' row object hashref and rebless result?
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
| Ilya Martynov (http://martynov.org/) |
| GnuPG 1024D/323BDEE6 D7F7 561E 4C1D 8A15 8E80 E4AE BE1A 53EB 323B DEE6 |
| AGAVA Software Company (http://www.agava.com/) |
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

On 13 Oct 2001, Ilya Martynov wrote:
> I'm not native English speaker so my dictionary is limited and word
> usage is not very accurate sometimes. I'm happy to accept your
> proposal for terminology :)
I realized why I don't like that terminology. Attached things can
generally be detached. BUt in this case once something it is attached it
cannot ever be detached (though it can be deleted). I'm favoring the term
live or actualized or something right now for the row after its in the DB.
Now I just need a counterpart.
> DR> Third, you have it validating updates but not inserts. I think either it
> DR> should validate everything or nothing. It might just be best to wait
> DR> until an attempt to insert to do all the validation. After all, you don't
> DR> even really want referential integrity checking til you actually do the
> DR> insert, so why check the nullable-ness and such?
>
> Sorry. I don't really understand about 'updates but not inserts'. As I
> understand on row object only 'update' operation is defined but no
> 'insert' operation. 'insert' is table operation which is a factory
> method. Or am I wrong?
All I meant is that when the row is made live it will be an insert behind
the scenes, which will go through the normal validation code. Therefore
for updates on a row that is not yet live, it may not be necessary to
validate.
On yet another hand, I like the idea of catching errors as early as
possible. I think I'll have it validate verything except referential
integrity.
> invented :) doesn't have to obey many strict checks for 'normal'
> objects. It is an object in 'half-baked' state so Alzabo should not be
> very strict with it.
Well, I'm changing my mind again (and again and again).
One other thing, I'm going to make it so this works.
my $row = $table->not_yet_live_row;
$row->update( foo => 1 );
$row->make_live;
$row->update( foo => 2 ); # now changes DB
$row->delete;
In other words, making a row live doesn't return a new row, it changes the
state of the existing object. This means that everything that has a
reference to it is still referring to the same thing. Fortunately, this
is pretty easy in Perl.
-dave
/*==================
http://www.urth.org
We await the New Sun
==================*/

Community

Help

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

I agree to receive quotes, newsletters and other information from sourceforge.net and its partners regarding IT services and products. I understand that I can withdraw my consent at any time. Please refer to our Privacy Policy or Contact Us for more details