Re: [Maypole] Auto Increment Primary Keys (and Documentation)

From: Peter Speltz (peterspeltz at yahoo.com)
Date: Thu Jan 27 2005 - 03:12:34 GMT


I don't really understand what you're talking about. Some code exemplifying
your problem would really help.

--- Gordon Haverland <ghaverla at materialisations.com> wrote:

> The way I thought I had to set things up, {\it vis a vis} database
> tables started requiring quite involved SQL queries for what
> should be fairly standard operations. So, I had to backtrack and
> change things.
>
> I have a couple of tables which are related, one of which has an
> auto_increment primary key. I can create a tuple (row/object) of
> data without ever mentioning this primary key as I understand
> things. Fine. But, is there some easy way to find out just what
> value was assigned to that variable?
> the modules behind Maypole, do I really need to search for the
> maximum value in the primary key column after I create the tuple?
> It seems to me, that if there is a high access rate on the
> application, that this isn't going to get me the primary key
> value I want anyway, some other process may have created another
> tuple in that same table between when my process created the
> tuple and when it searched to find the maximum value of the
> primary key.
>
> I would have thought this would be a common requirement, since the
> value of the primary key column in a tuple is often used as a
> foreign key in other tables. But I just don't see it anywhere.
> Are the creates for the associated tables supposed to get this
> value automagically?
>
> On the wishlist side of things......
>
> Documentation or examples in general of all Maypole stuff are
> still needed. Beer (and Maypole) looks very much like: we want
> almost everybody to be able to look at every table. Flox looks a
> bit more like my (first) application, I really only want an
> authenticated user to be able to access a single row of a view of
> some part of the database tables, most of the time. Since SQLite
> only has read-only views, this means doing everything explicitly
> as near as I can tell (and not trying to build a SQL view). But
> searching the documentation usually produces little or nothing at
> most turns, so I am guessing a lot. My guessing is getting
> better, but I still wish the docs were better. At this point,
> the rewrites required I think are producing a better product.
> But it would be nice to be able to get this to the point where
> (l)users (of my project) could start trying it out. :-)
>
> Gord
>
> _______________________________________________
> maypole mailing list
> maypole at lists.netthink.co.uk
> http://lists.netthink.co.uk/listinfo/maypole
>

=====
pjs

        
                
__________________________________
Do you Yahoo!?
Yahoo! Mail - You care about security. So do we.
http://promotions.yahoo.com/new_mail

_______________________________________________
maypole mailing list
maypole at lists.netthink.co.uk
http://lists.netthink.co.uk/listinfo/maypole



This archive was generated by hypermail 2.1.3 : Thu Feb 24 2005 - 22:25:57 GMT