Re: [RDBO] Database Permissions when inserting (relationships).

2008-01-10 Thread Curon Davies
On Jan 9, 2008 20:02, John Siracusa [EMAIL PROTECTED] wrote:
 In the meantime, you can always express more explicitly the operations
 you intend to perform.  For example:

 $product = My::DB::Product-new(
   name = $^T,
   add_prices =
   [
 { price = 3.60, region = 'uk' },
 { price = 7.00, region = 'us' },
   ]);

 $product-save;

Thanks for that suggestion, something that I didn't think about. The
add_ prefix doesn't look that nice in the constructor. As we would
probably need to use it everywhere we create new objects for inserting
into the database, we will probably override the constructor in our
base class to to call the add methods instead of the 'get_set_on_save'
method for both 'one to many' and 'many to many' relationships.

The only problem is that our code manipulates the object before
deciding to save the data (e.g. does our own additional validation).
With this I can't find any way of getting to the objects that will be
added, as $product-prices returns the empty list.

my $product = My::DB::Product-new(
name = $^T,
add_prices = [
{
price = 3.60,
region = 'uk',
},
{
price = 7.00,
region = 'us',
},
],
);

use Data::Dumper;

print Dumper [$product-prices];


If the add_on_save method is called with no parameters, then it might
make sense for this to return a list of objects that will be added (if
one wants to ensure that an empty list isn't passed to this method,
then an arrayref could be passed instead). I still think the
get_set_on_save method should return both what is already in the
database (unless the object isn't in the db, the primary key isn't set
and the column type is serial), along with those that are going to be
in the database when saved.


Thanks
Curon

-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
Rose-db-object mailing list
Rose-db-object@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rose-db-object


Re: [RDBO] Database Permissions when inserting (relationships).

2008-01-10 Thread Curon Davies
Hi John.  Thanks for your help on this.  Unfortunately that still
doesn't quite work.  If we do:

  $product = My::DB::Product-new(name = $^T);
  $product-add_prices(
{ price = 3.60, region = 'uk' },
{ price = 7.00, region = 'us' },
  );

and then:

  my @prices = $product-prices;

@prices is empty.  Whereas if we set them using prices as an argument
to new (like in my original test) $product-prices can be used to
retrieve them, even without calling $product-save.

After calling new, I need to be able to access the objects created
when passed with the 'add_prices' parameter, in a different (custom)
method before saving the objects into the database.

Is there any way we can retain this functionality while not requiring
DELETE database privileges?

Thanks.
Curon

-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
Rose-db-object mailing list
Rose-db-object@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rose-db-object


Re: [RDBO] Database Permissions when inserting (relationships).

2008-01-10 Thread John Siracusa
On Jan 10, 2008 10:01 AM, Curon Davies [EMAIL PROTECTED] wrote:
 Hi John.  Thanks for your help on this.  Unfortunately that still
 doesn't quite work.  If we do:

   $product = My::DB::Product-new(name = $^T);
   $product-add_prices(
 { price = 3.60, region = 'uk' },
 { price = 7.00, region = 'us' },
   );

 and then:

   my @prices = $product-prices;

 @prices is empty.

Yeah, because it's not sure that $product doesn't already exist in the
database with an existing set of prices, so the actual list of prices
is still unknown.  (It's keeping the list of prices-to-add off to the
side, awaiting save().)

To make it sure that there are really no other prices, you either have
to fetch them from the db (which requires defined values for the local
columns that participate in the prices one-to-many relationship) or
you have to set them.  (Even setting to an empty list [] would work.)
Of course, the setting option gets you right back to where you
started, so that's no good :)

 After calling new, I need to be able to access the objects created
 when passed with the 'add_prices' parameter, in a different (custom)
 method before saving the objects into the database.

Why not fiddle with the prices objects *before* passing them to add_prices()?

 Is there any way we can retain this functionality while not requiring
 DELETE database privileges?

I'm open to suggestions.  Can anyone think of a good way to make this
work without breaking some existing functionality?

-John

-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
Rose-db-object mailing list
Rose-db-object@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rose-db-object


Re: [RDBO] Database Permissions when inserting (relationships).

2008-01-09 Thread John Siracusa
On Jan 9, 2008 2:05 PM, Curon Davies [EMAIL PROTECTED] wrote:
 The file works fine if the User (in this case 'rose_test') has DELETE
 permission the on 'price' table, but fails otherwise. From my
 prospective this should definitely not be the case, as the only action
 performed here is inserting into the database. Of course, I could call
 the insert method, but that defeats the point of having a common save
 method.

In your test, you are setting the prices one-to-many collection:

$product = My::DB::Product-new(
  name = $^T,
  prices =
  [
{ price = 3.60, region = 'uk' },
{ price = 7.00, region = 'us' },
  ]);

$product-save;

Setting the collection means replacing the existing contents (if any)
with the new contents.  So the queries actually run are a DELETE and
then a series of INSERTs.

Now in this case you may know that this is a new record, but the
code does the same thing regardless.  This is mostly done as a
safeguard or guarantee that setting a collection always really sets a
collection's entire contents.

Arguably, a feature could be added that would let the programmer
specify that these objects are not expected to already be in the db,
so don't bother with the DELETE before setting the collection.  Maybe
save(insert_only = 1) or something?  Maybe others have better ideas?

In the meantime, you can always express more explicitly the operations
you intend to perform.  For example:

$product = My::DB::Product-new(
  name = $^T,
  add_prices =
  [
{ price = 3.60, region = 'uk' },
{ price = 7.00, region = 'us' },
  ]);

$product-save;

There should be no DELETE queries issued for that, though it may look
a bit odd to be adding to a collection that you expect to be empty
to start with (although that seems valid to me).  A comment before
such a block could explain this, perhaps.

-John

-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
Rose-db-object mailing list
Rose-db-object@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rose-db-object