Shaun, Thanks for the reply, good to hear some strong objections.
First, i'm 99.9% sure this is the only app that will be generating ids for this database, but i do agree with that point. I have full control over all apps that would ever generate PKs for my db, i can make sure they won't conflict. I guess the point of a GUID is that I won't have collisions, or the possibility is so small, i'll take my chances, i'm not talking about millions of transactions. I did think about creating a temp id and the translating when it comes back down... but i'm trying to avoid having to send someting back down after i post and save my xml to the database. Another thought is that when my app loads, i'll just download X number of new ids that are available so i know (since the server gave them to me) they are unused, no collisions. I would say the stragety i'm trying to accomplish is not great for large teams, but in this case, i'm one developer, one database. If this product takes off and makes a ton of money it can always be redesiged later... for now, i'm trying to cut a layer out of all the server side to client ui mapping for sake of development time. --Scott --- In [email protected], shaun <[EMAIL PROTECTED]> wrote: > > Hi, > > scott_flex wrote: > > Thanks for the reply... i probably will look into writing my own > > implementation. Never really thought of it... > > > > Generating GUIDs on server, while i can do that, just makes more > > sense if it's done in the flex app itself. > > > > No, it doesnt. > > > and yes... these IDs will be used as primary keys in my database... > > at least that's the current design i'm thinking about. > > > > Your kidding.. > > > I'm generating an XML document in my flex app, where each > > node/element and its attributes represent a single row and child rows > > in a parent child/foreign key relationship. > > > > When i call a web service, i get my xml document which contains pre- > > existing primary keys but when i add elements that have not yet had > > been persisted to the database i don't want to both send up my xml > > data and then turn right around and pull it back down just so my new > > xml elements/nodes have the correct primary keys attached. That's > > especially important when i save/send up the xml a second and third > > time. > > > > If i can assign my IDs earlier in the process, that solves that > > issue. I still have to check pre-existence on my server side when i > > actually commit my changes to either run an insert or update sql > > statement. > > > > What will happen with things like collision handling or other > applications wanting to insert into the database in future etc? Do they > have to ask you to generate them a PK with your > "special actionscript function"? ;) > > Why not do something simple like assign a tempid on the client, do the > all the DB stuff on the server and return a list of > temp_client_id=server_side_id key/value pairs, then put those values > back in the xml on the client? Should be simple enough. > > At least that way you are not generating database primary keys in your > client app. You can also implement a strategy on the server side so your > client app never gets a real database PK. > > cheers, > shaun >
