Thanks guys for all the help, I'll have something to digest now and learned
already a lot!
Just a short reply to the ORM versus SQL issue:
Yes you are right, you have to pay for the abstraction but then, if you manage
to fit it all in, it pays off.
I can see it with lots of scripts I developed f
Ask Bjørn Hansen writes:
>
> On Dec 5, 2006, at 9:00, George Hartzell wrote:
>
> > On the other hand the hoops that they jump through to try to
> > automagically generate queries and hide the relational database
> > mystifies me, I find that I end up double checking the sql that they
> > g
On Dec 5, 2006, at 5:42 PM, Perrin Harkins wrote:
> This can also be done in a one-shot, without needing to explicitly
> lock
> anything:
>
> UPDATE foo SET id = id+1 WHERE
nice catch.
i wasn't even thinking of sql. i was just trying to consolidate the
original example.
// Jonathan
Jonathan Vanasco wrote:
> lock table
> read last_used_number( year )
> increment last_used_number( year )
> unlock table
This can also be done in a one-shot, without needing to explicitly lock
anything:
UPDATE foo SET id = id+1 WHERE
On Dec 5, 2006, at 9:00, George Hartzell wrote:
> On the other hand the hoops that they jump through to try to
> automagically generate queries and hide the relational database
> mystifies me, I find that I end up double checking the sql that they
> generate to make sure that I haven't shot mysel
a- if these numbers are just metadata, then fine. if you're looking
at this non-unique invoice number as some sort of record identifier,
i'd strongly suggest against that and just making it metadata.
b- i would do this:
use a helper table with the columns "year" and "serial"
> "Michael" == Michael Lackhoff <[EMAIL PROTECTED]> writes:
Michael> Is there an idiom for this kind of task? And how can I do it with
Michael> RDBO?
You will never have perfectly sequenced numbers, unless you're willing to
accept a fairly serious slowdown in assigning those numbers. The big
Michael Lackhoff writes:
> On 5 Dec 2006 at 11:02, Perrin Harkins wrote:
>
> > You can usually do this kind of ++ thing in one INSERT...SELECT statement:
> >
> > INSERT INTO invoice (id) SELECT MAX(id)+1 FROM invoice;
>
> That's clever! Though it seems to slightly defeat the point in usin
Michael Lackhoff wrote:
> Though it seems to slightly defeat the point in using
> RDBO: To have Perl, classes and methods instead of SQL, tables and
> columns.
Abstraction is certainly one reason to use an ORM, but I think it's a
bad idea to stick strictly with your ORM if it prevents you from
On 5 Dec 2006 at 11:02, Perrin Harkins wrote:
> You can usually do this kind of ++ thing in one INSERT...SELECT statement:
>
> INSERT INTO invoice (id) SELECT MAX(id)+1 FROM invoice;
That's clever! Though it seems to slightly defeat the point in using
RDBO: To have Perl, classes and methods ins
On 12/5/06 11:08 AM, Michael Lackhoff wrote:
> On 5 Dec 2006 at 10:32, John Siracusa wrote:
sub generate_invoice_number
{
my $class = shift;
my $db = My::DB->new; # Rose::DB subclass
>>>
>>> Why not just use the default here?
>>
>> What default?
>
> The on
On 5 Dec 2006 at 10:32, John Siracusa wrote:
> >> sub generate_invoice_number
> >> {
> >> my $class = shift;
> >> my $db = My::DB->new; # Rose::DB subclass
> >
> > Why not just use the default here?
>
> What default?
The one that is inherited from my common base class (I fol
Michael Lackhoff wrote:
> I need some pseudo-unique numbers like invoice numbers. They start every
> year with 1, so autoincrement won't work. My idea was to use a helper
> table with just just two fields 'year' and 'last_used_number'. Is it
> enough to create a two column unique key or would it be
On 12/5/06 10:18 AM, Michael Lackhoff wrote:
> many thanks for your help, the only part I don't understand is why I need a
> new DB object:
Well, you need *a* db object from somewhere, and you need to share that db
object among the manager, the row object, and the places where you lock and
unlock.
Hello John,
many thanks for your help, the only part I don't understand is why I need a new
DB object:
> sub generate_invoice_number
> {
> my $class = shift;
> my $db = My::DB->new; # Rose::DB subclass
Why not just use the default here?
> my $num;
>
> eval
>
On 12/5/06 8:19 AM, Michael Lackhoff wrote:
> I need some pseudo-unique numbers like invoice numbers. They start every
> year with 1, so autoincrement won't work. My idea was to use a helper
> table with just just two fields 'year' and 'last_used_number'. Is it
> enough to create a two column uniqu
On 5 Dec 2006 at 8:41, Sean Davis wrote:
> > Is there an idiom for this kind of task? And how can I do it with RDBO?
> > (I did a search for 'lock' in the docs and didn't find anything)
>
> Are you using postgresql? If so, could you use a sequence and set the
> sequence back to 1 at a specified
On Tuesday 05 December 2006 08:19, Michael Lackhoff wrote:
> Hello,
>
> I need some pseudo-unique numbers like invoice numbers. They start every
> year with 1, so autoincrement won't work. My idea was to use a helper
> table with just just two fields 'year' and 'last_used_number'. Is it
> enough to
Hello,
I need some pseudo-unique numbers like invoice numbers. They start every
year with 1, so autoincrement won't work. My idea was to use a helper
table with just just two fields 'year' and 'last_used_number'. Is it
enough to create a two column unique key or would it be better to do
something
19 matches
Mail list logo
