> > If there was a way to do it in a stored proc, that would > probably be > > fine even if the syntax of the proc differed - because the > proc would > > be part of the schema, just like table and index > definitions. As long > > as the call syntax would be the same. > > > > However, I don't beleive sqlite does stored procs, and I > doubt it's in > > the plans - doesn't really make sense for an embedded db. > > Yes, that's about what I meant with "major differences" > between the RDBMs...
Yeah. It's a problem utilising databases with so hugely differnet featureset unless you accept having different codepaths in your own code. The only option if you don't want that, is to use the least common denominator, which leaves you incapable of using the featureset of the more capable databases. > > The best scheme would probably be SELECT->INSERT->SELECT (second > > select if the insert failed). That you can do with > SAVEPOINTs (around > > the INSERT). > > Why would you need anything - SAVEPOINTs, in this case - > around inserts, or rather what *is* a savepoint? A savepoint is basicaly the capabilty of doing half-a-rollback. So you can do BEGIN TRANSACTION SELECT ... INSERT ... SAVEPOINT foo INSERT ->oop, failure ROLLBACK TO SAVEPOINT foo COMMIT > > Another thought - does the filename *HAVE* to be unique? > > Difficult question, at least for me. This would be something > best discussed with Kern and perhaps Dan, I guess... > > The basic idea is appealing, though. I beleive it would make it a lot easier to do many concurrent updates, and it would make it possible to use transaction grouping and things like that in an easier way. If it works, that is. > > You can gain a > > lot of concurrency if you say "I want to use the existing one in > > 99.99% of the cases, but I don't care about reaching 100%". > Then you > > can do > > SELECT->INSERT and the INSERT will *always* succeed. In case a > > concurrent proces sinserted the same name, you get two ids for the > > same name. You could either live with that, or clean it up > at the end > > of the job, perhaps? > > Might be some task for dbcheck. Depends on how quickly you need it to get up-to-date. > > (or is this perhaps already done today? Since there is no unique > > constraint on it?) > > I suppose the reason for not having constarints wherever > possible is that older versions of MySQL, AFAIK, didn't support those. AFAIK, even MySQL has always had UNIQUE constraints. Or did they have one of those things that you couldn't put unique on more than one column? I thought they did, but I don't know too much about older versions of mysql. For a long time it was the only kind of constraints they supported, though. > > (Sorry if I'm ranting about things that are completely out of the > > scope you were talking about ;-)) > > Nothing to worry about - you gave just the answers to my questions :-) Being a database guy, I sometimes to get off on a rant when the topic comes up ;-) //Magnus ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
