---
title: WWDC2003 Session 616
framework: wwdc
role: article
path: wwdc/wwdc2003-616
---

# WWDC2003 Session 616

## Transcript

Kind: captions Language: en my name is Ben Trumbull and i'm a senior engineer with the development technologies group here at Apple and Steve miner is going to be assisting us with some demos and he's one of our fellow engineer so this year we're going to try to do something a little bit different we're going to try to provide a brief overview of a variety of topics some topics that are challenged you in the past so last year we talked about some things with validation and key value coding and we're going to try to just skip over all that stuff so basically the session isn't about anything you can find the documentation for the most part and the documentation of particular relevance to this particular topic eof is going to be the 5.2 Delta documentation and I believe they call it what's new in 5.2 on the website and the eof developer guide so kind of a show of hands of who's actually read the republish eof developer guide it was redone rewritten this februari so Brent shank and all the people in tech pubs did a fantastic job rewriting this includes Mostyn material includes most material from last year's advanced session so we're going to have to keep pushing further so when I said a brief overview we've got about five slides for all multi-threaded programming this is going to go pretty quick it's really more about identifying obstacles and getting you to ask the right questions and then you can go back to documentation or community resource one of the mailing list to get more information so first on our agenda is memory management and us we're going to assume you know something about how garbage collection works in Java and the difference between strong and weak references some interesting point is you can create your own subclass for weak reference and UF does this it's a handy little trick eof also uses a mechanism called false and false our enterprise objects that have not been initialized yet so they're lazy initialization at work and they provide assistance in memory management as the boundary for the active object graph everything beyond the fault is not fetch from the database deferred faults are a special kind of fault using too many relationships and there definitely more memory efficient because until you touch them the first time they are empty if they don't have anything they're just a little fault and then they grow to expand to include one fault for each object in the queue many relationship and finally share it in context another mechanism you can use to reduce your memory and it's probably best to think of these as read-only object stores and we'll talk more about that later so a lot of changes went into 52 that are under the hood so hopefully not too much epi impact on you but a lot of things did happen and the first is a lot of complaints about editing context using strong references to their Enterprise objects this has been changed Enterprise objects are now held with weak references so the garbage collector can come along and just start pruning the object graph of things that you're no longer accessing directly only modified objects or things that are inserted deleted or updated our skill rate retained an enterprise objects have a reference back to their editing context now and it will hold the editing context in memory until it's done using it so you have to be careful not to have any Enterprise objects floating around but this is better than previous years where if the editing context guard was collected first the enterprise optics is no longer very useful consequence of these changes is that the registered objects method is not really useful since these objects who's going to be pruned just sort of randomly by the garbage collection thread you can't count on anything still being there I know people in the past have bound their boat components to this method to just grab everything in the editing context you really are never going to know what you get if you want to lock in object wrap into memory you can use set retains registered objects on it editing context and you can only do this when the edingtons doesn't have any objects in it but that will change the way it works and it will hold everything with strong reference and share that in context always use strong references otherwise they wouldn't be very useful so a bit about faulting something many people don't realize is that the size of your fault is the same as the size of the enterprise object that represents referred faults as I mentioned earlier are significantly more memory efficient than the too many relationships they represent and enterprise objects can extend your generic records to transparently in harris the deferred faulting future if you subclass directly from you a custom object you're not going to get deferred faulting by default and away from scratch can't wait for insertion so this is on the faulting page because faults are constructed the same way Enterprise objects are and this is due to strong typing in Java so we've got to create a new enterprise object when we're creating a Fault in vice versa it means that if you have a constructor on your enterprise object you're going to start doing things while we're faulting this is bad it defeats the purpose of lazy initialization in addition when the fault gets fired that's when iOS thinks that it's going to finish the initialization so it's going to overwrite stuff and it might just ignore things completely and typically at the time that the constructor in an enterprise object is invoked by the vm that object is not inserted into the editing context yet so that means any changes you make in there aren't going to get noticed by the editing contact and that breaks pretty much everything so you really really have to use away from fetching away from insertion and so some basic memory optimizations blobs and clubs should be factored into their own tables and access to a relationship and then the relationship can be faulted and keep the in-memory object graph is small as possible some other things that some people do you know you don't want to over optimize too early but having too many relationships not be a class property can be very helpful so there's a lot of overhead and managing relationship or there can be particularly for very large too many so if you don't need both sides of the relationship between two related AOS you can have it be a uni-directional relationship instead of bi-directional and you can put rarely use attributes across the relationship the same way you would with a blob or a clob and you can replace it too many entirely with a set and one of the nice things about this is it can be vended as a java method and two key value coding and the rest of us it looks exactly like in a property on your enterprise object but instead I can be a hand coded fetch it's doing something special so shared editing context I like this pinch of this is probably one of the most badly named classes and us and it's not that it's too long or too short and it's not that technically it's not a shared in context it is unfortunately the best behavior is a read-only object store it's not really an editing context and if you try to use it just like an editing context you're going to run into some problems and if you try to use it as a shared area of read/write use they're also going to run it from its best is using read-only years in here and then you can modify other ears related to them in your regular editing contest the main advantage of this despite those complications is you get to reuse the memory for the entire enterprise object instead of just the row level snapshot which is what normally happens between editing context and it's very important not to have outgoing relationship so if you have a relationship coming from a shared year going into any oh and a regular editing contact us will be very unhappy with you and share that in context and regulating context should all use the same objects or coordinator so much more than that insect so you've got a million he is the most important advice I can give you to defy the operations in two batches most users are not going to interact with a million years at the same time anyway and if they're browsing through a result set they're probably going to browse the first few sets before they get bored so that's the best advice you can use raw rose and you can fetch bad just the primary keys or some other subset of the year so you don't have to bring the full yo into memory and project wonder already has some of the stuff done for you so you can use their such specifications batch iterator to do batching and it basically actually incorporates all these ideas and they just tons of stuff in project wonder so more advanced techniques that you can use is you can intercept the roads as they're being fetched at the adapter level and you can use a custom jdbc channel subclass it can override set row and as you're going through you can use a row and then throw it away and in this way us will not keep all of the result set in memory and dave newman who is one of the speakers for the previous session actually has done this and got an order of magnitude improvement in peak memory use for one of his reporting tools so it works okay so next on our agenda is data freshness the u.s. is a big cash and it's cashing the rows from your database and editing context build an object graphs mapping on top of this cache the data freshness is about when and how to refresh his cache lines and in us we call them snapshots reef all thing is about taking an enterprise object and turn it back into an uninitialized fault this is an important mechanism for saving memory as it prunes entire branches out of the object graph invalidating is a little bit like resulting and a lot of people get the two mixed up the main difference is unlike gently sharing the object graph you're using a chainsaw such time stamps measure staleness for those snapshots and the EO database object is to cache object that you can work with and you can get at it through the EO database context through your objects for coordinated so just to really kind of home in on why resulting is much better than in validation resulting effect only one editing context there are no notifications no effect on other editing contexts or other user sessions the existing snapshot gets reused if it's fresh enough and there's no trip back to the database so it's much more gentle on your performance now if the snapshots to scale then it will have to go back to the database research that row and get you something that's fresh enough for your configuration and that will post a notification invalidating affects the whole stack infects everyone using that object store coordinator editing concepts can lose changes for that object because you've just smashed it and the snapshot will be discarded and the next time any editing context touches that object which is now a fault around trip to the database will occur now sometimes you do have to invalidate so some things keep in mind you really don't want to end up in a position where you basically invalidate a lot of objects there now salt and you're going through and you're telling us one at a time is firing us all to go back to the database because that's going to cost thousands of round trip to the database that's something you want to avoid basketball thing in your relationship can help them merely ate some of this but really a manual fetch with an object of such sophistication is probably the best way to go you invalidate a set of fix that you know about and then you go and you do a fetch for the working set that you expect to be using next in this way you're going to minimize folding and prefetching keypads are extremely useful for doing this and grabbing a whole lot of data at one so refresh object I believe this is introduced in 5.1 it's a smarter reef alt object it merges changes back into the enterprise object in that editing context so it'll pick up any changes that occurred to the snapshot it skips over inserts which can't be resulted and it reuses the existing Road snapshot unless it's too stale so the most important thing to understand about sketch timestamps is they just don't work the way you want them to such timestamp lag is relative and it defaults to one hour and you're not really going to have a whole lot of interaction with this but what this means is when a new editing conduct its created its fetch timestamp gets set to one hour ago and that's all the data it considers fresh enough so those such x clamps are always absolute like June twenty fifth for 15 p.m. if we created an edited context right about now and no matter how long that in context stays around say three days in your application it's going to consider all the data since jun 25th for 15 p.m. to be fresh enough most people don't want that and right now you're going to have to work around it by periodically resetting the fetch time can a good places do that is in session awake that's a great time a callback you know the users now interacting with that default session editing context again you can also refresh rose with a fetch specification and setting the set refreshers refreshed object flag and did i mention prefetching is a great way to get lots of data at once so another advanced technique and i haven't seen very many people do this the EO database is your snapshot cash and UF is a big cash so by directly manipulating this object you can do some pretty cool things and really improve performance you can cheat it faulting if you've gotten a row backs in the database using raw rose or one custom used some custom jdbc code writing rod jdbc code he implemented a cursor pulled that stuff back and now he sets those roads into eos it records the snapshot called salt for global ID and it's good to go you can also preflight a to many relationship this is a pretty readable for inserted years since 30 years begin life with a too many fault and most of the time that's salt when it goes to database they aren't going to be any records there because it's a brand new yeah sometimes it could be if you've got multiple writers but for the most part those relationships tend to be empty but EF doesn't know that so the first time you touch that fault you modify that newly saved object it's going to fire going to go to the database and it could be there could be a lot of records there so you might want to just skip that and you can use record snapshots the source global ID to do that and to refresh it too many snapshot a lot of people ask questions about this so passing null not a blow away the snapshots for that too many relationship and then it'll be researched and you have to remember to lock and unlock the object store a coordinator and that's the one that's associated with the database context that's using this co database object okay so we're going to spend some time that optimistic locking now there's an entire chapter on optimistic locking in the new eof developer guide update strategies and mostly the subject is about dealing with multiple writers affection same data basically is about cat solidity and what to do when multiple people change the same thing and this can happen when you've got deployments with multiple web object instances if you're using a single application you've got multiple objects or coordinators they're going to have their own channel to the database and they can make changes they interact with each other or you have external writers telling we've got an admin app that's doing raw SQL or something outside your control so the material we just talked about and data freshness is pretty important in avoiding this problem obviously if you don't ever modify scale data you're going to be much better off so you can tweak your fetch timestamps to keep the data freshen up if you keep the data to freshman new health performance problems as you're always going back to the database and you can also implement code to propagate a distributed notification our u.s. does not at this time implement the Tribune notifications itself there are a variety of third-party solutions in here too one from wire hose and once in project wonder and they're both free so you can check those out recovering from this problem they think we have to catch an ear general adapter exception we're going to have a demo and I'll show you where that is it's also in the developer guide but basically that's your hook for implementing a recovery specific to your application because eos doesn't know if you want to have the first save win the last save win you wanted to emerge it's really specific to what you're doing the EU adapter operation in the user introduction of that exception is one of the most important parts and got the attempted road changes in operation type code so inserted updated deleted or locked and then the EO database operation has a reference to the enterprise object as well as the added sync stale snapshot and as you're recovering from NASA mystic locking exception keep in mind that reef alting is going to remove that ye o from the updated list so if it's a deleted or updated object it's just going to get reef altered and the editing context is going to forget about that and you can't result a newly inserted Enterprise object so it's best to basically pull out the deltas from the enterprise object ree fault it and then apply those Delta's again and in the process of applying those Delta's again to get any context emotes that the object is changed again okay we're going to go to demo to now and something new in webs 5.2 is multiple channels to the database you do simultaneous operations we're going to talk a little bit more about this later but basically you're just creating your own object store coordinator and we've got a new thread here and I'm doing something pretty simple just to show you how to recover for an optimistic locking exception and in my application constructor I just create this new thread so first you're going to want to do the save and catch the general adapter exception and then you're going to have to check the user info a dictionary to find out whether or not it's actually an optimistic locking exception or something else entirely so you can do that by getting this key out of the dictionary and then checking handy little method this is documented but it is a little obtuse so go through all this when you handle all this you want to get the adapter operation out of that user intra dictionary which has got everything just sort of jumbled together and from that adapter operation you get the operation type code which you can use to decide what you want to do as well as a database operation here on a database of operation has to your failed deal you can get a delta fiction area from the adapter operation and the current snapshot from the database operation and leave in this example I just assume i'm using the sessions default editing context but you can pull the editing context off of banter prize of itself if you want to and our recovery mechanism is just last right wind which is he here we grab the delta above from the adapter operation you result the object and this line we just you've used for our component we apply the changes and we'll go back and say it again because it's a little loop this is just using the real estate example framework and housing prices aren't really going up very much anymore they used to be going out more and so these are a whole bunch of things that our background thread decided to change while we were working at it it's pretty much throw back the slide and next we're gonna talk about multithreading and us so there are a variety of good books available about multi for Engine Java and we can't really go into just general multithreading in Java because that's a pretty big topic concurrent programming in Java by Doug leaves in my library it's a pretty good book on there just a zillion of them you probably wanna pick up several so some necessary contact concepts that we're just going to skip over synchronize methods and synchronize blocks tri finally blocks and the wait and notify methods on object and then the web Bob's expect them to Delta dock be what's new area has more information about locking issues specific to EOS job applications are always multi-threaded whether you like it or not the object finalization thread so this has nothing to do with objects the objects finalization occurs in a separate thread so if you have a finalizer those finalizar methods are going to get executed in another thread that's just the way it is with web objects applications is also the session timeout thread and that's also going to be doing eof operations and then their timers for notifications long requests pages and any threads you create yourself like we did in the demo so here's proper used to try finally just want to lock the resource do to try use it you really never want to mess with the lock object itself it's extraordinarily difficult to do properly it usually involves having another lock object just to manage it kind of Heisenberg effect so you pretty much want to leave those alone so AOS contract with you and this is again talk to more about in the Delta doc is that you have to launch everything that you access directly it's just the way it is the locking in addition to everything else does how keep us informed about what resources using at any given time the NF locking interface r is for all the objects that support thread safe use objects who don't implement NS launching like NS raised and in s dictionaries you don't have to protect yourself so you can just create an NS recursive lock to do that trilok is amazingly useful and it's supported by NS recursive lock n do editing context two of the main interactions with locking and what this lets you do is execute an operation only if you're certain you won't block so that's great you can queue up an operation happen later if you think you will block and it's used in the notification delivery mechanism control / or killed s quit to the process ID produces a stack trace of every thread in the JVM and I can't recommend this to highlight it's a phenomenal debugging aid you get to see what all the threads are doing the JVM will tell you which locks they're waiting on it's really the only reason I'm still here optimized it in jaypro for both commercial products they can help you debug multi-threading issues and they also support memory performance and cpu performance of profiling so they're really great products you can check them out the main launch you're going to interact within us is on the editing context this controls all kinds of things now it's true that nested editing context share the same lock as their parent however you still have to lock it this is the contract that you have with us and he OS has with you basically the only consequence of this that you can depend on as multiple threads can't come in and use the same hierarchy of nested ending context at the same time you can't cheat is locking this way well you can try but shared any context lock themselves and they're the only objects in you have to do so otherwise it just gets me a nightmare to maintain them but basically they're the only object and you have to do this and it's really important to launch everything else you always have to launch the editing context before you access any of its enterprise objects so even operations you think would be read only or sort of intrinsically fred space they're not there's fault thing going on behind your back there's a lot of cashing in the frameworks themselves it's going on a lot of transparent operations to keep the object rest maintained keep memory down you just have to lock everything and the e objects coordinators will lock all of their cooperating object stores if you ask them the lock directly and those usually give you a database context so what you see here is a thread view of the EOS snack the EO object store coordinator is the focal point it's sort of the center of mass for eos and it serves as a mediator between the EO control and the EO access layer this diagram is a little oversimplified there call back some delegates and stuff but this is your basic idea of how threading work in EOS and the obvious where coordinator is the center of it all so multithreading an eof there are a couple remaining bottlenecks the critical sections and your classes can be very small but if you're doing something that does a lot of models or entity work you're parsing models or you're creating your own models on the fly you should be aware that there's some concurrency implications there and the allows concurrent requests handling swagg only affects webobjects the web objects frameworks not web objects and us this affects how requests are dispatched to both sessions and direct actions and any other request handlers you have and it has no effect on us like I said both the object finalizer thread and the session timeout thread are going to be doing us operations whether you like it or not and this is to deal with memory management and snapshots and a bunch of other things so it's really important to keep the editing context lock properly one thing I have seen some customers do is they launched an editing conflicts they use it to do one little thing and then they unlock it you can lock it for as long as you need to write if you're not going to share that at any contacts with another thread you can just keep it locked you don't have to make the locks really fine grained that's the point of implementing these locks on these objects is to allow you the flexibility to control the grain of belonging so my life might have purpose some stuff that I learned painfully while working on us non-parallel locks are like debt if you've got more than three locks and they're all somehow related you will regret it intersecting locks increase the probability of deadlock so the Morlocks that any thread needs to acquire to get its work done the greater likelihood some bug is going to come along and cause your application to deadlock because some threads love them in the locks in some threads with other locks and this is a permutation that increases combinatorially it's ugly and unfortunately these apps tend to work very well in development and not so well in deployment under high stress after many days so those are kinds of bugs I like to avoid something a lot of people don't realize is the synchronized method and the synchronized block these are their own implicit lock object and it's on either that java.lang.object or the java class that you're working on depending on the kind of synchronized statement so you can you can deadlock with these and you can cross block with the synchronized statement and an actual lock object and if you come in and you block inside a synchronized block you do some IO or you try to grab a different lock no other thread is going to be able to do anything involving that object with that synchronize so it's not gonna be able to execute any synchronized methods not even a little one line setters and getters and it's usually not what people intend to have happen so if you're going to lock for something that you expect my clock like either acquiring a new lock doing some io something expensive you should do it outside a synchronized scope and you can use the NS recursive locks I prefer that because it allows you to use the tri finally syntax regardless of what the call stack looks like so you can just keep invoking methods recursively or not or to use java's we can notify protocol if you should comfortable that okay so we're gonna talk about a new feature in web barbies 5.2 into concurrent database access and that's putting all those new threads that you learned how to create to use and to do a bunch of things simultaneously with your database as a diagram showed the EO object store coordinator is the root of everything in the eof in terms of threading so each EEO object store coroner has its own stack underneath it also in set a lock with own database channels and its own snapshot cash so they're extremely independent notifications between them don't hold our notification there are no notifications in between them so they're very independent it's pretty easy to do just create a new one pass it on to the constructor for your editing context you can also change the default object store coordinator and I believe in project wonder there's now an object or coordinator pool you can use so you can use these independent snacks any way you'd like but there are some benefits to using roro operations with these stacks and that's there's no overhead from duplicated snapshots so there's less memory use and you're not worried about propagating notifications the actual concurrency is throttled by your database so you have to make sure that your database is set up to keep adding more channel all right and we're on to raw rose so these are the lowest level operations you can use an eof and they allow you to bypass the entirety of control layer they'll return a result set in NS array of nsdictionary and each roro is itself an nsdictionary there's no object grass management no undo redo no relationships no faulting which may be good and there's no Road Cashin and you can use hand coded SQL so the EU effects specification you can just take a fetch specification you set this flag and you'll get back we're all rows instead of enterprise objects really easy to do probably the best way to get started you can also pass in the custom SQL hint and this will allow you to happen optimized SQL something specific to your database or you can do something that you won't generate automatically for you my other favorite is raw rose for SQL really easy to use and there bunch of other areas in EOS where you can interact at this level so some things to keep in mind while you're using raw rose is that both Enterprise objects and dictionaries implement and its key value coding so you can make instance variables types to NFC value coding the interface and then as you're processing the results from either and enterprise objects request a fetch or a raw raw fetch those results can be displayed in the same code so the same code path can reuse them that's really useful with low components or UI layer work you can promote raw rose into full ears as long as you fetch the primary key attributes and you can demote ears back into the primary keys if you want to return to bare metal work and the stink movies example that ships with develop sticks demonstrates these ideas so it uses the primary key to do direct action based work and there's no sessions so there are a couple features of us doesn't provide at this time and you can use raw SQL to get through these features they're pretty handy so there's in qualification and null relationship qualification or sweat sub queries and again project wonder has got some of these things built in for you for their quarry operators for you and good reason to go check it out and now Steve miner is going to come up and give you a demonstration hi thanks then all right I have a demonstration here for how to execute the sequel using the u.s. stack I've written a little sequel tool that just is similar to any command line tool that you might get from your database vendor the advantage to my tools I can use it with any models and if I don't have a local database centers sequel tool I can use this to make changes to my database or just to explore a little bit on the data now before I get into that I want to show you the code it's very easy to execute a bit of sequel first thing you need to do is you're working at the EU access level not the you control level so we're bypassing all of the object graph we're going to load a model it'll take this line here so to load a new model you just need to know the past your model or you can pick up the model that's already been loaded by us you can add that model to a group that the model group you take a look at that that's just a way of grouping multiple models you probably use that when you're developing your applications the model group knows about all your entities across the set of models you have to make sure you don't have any end named conflicts within your group so the next thing you have to do is collect and after give it a model you can always say adapter with model that will instantiate the adapter and that allows you to make your connection to the database the adapter context is your scope for your transaction you don't have to interact too much with your adapter context but the adapter context also allows you to create a channel and channel at the adapter level is the entity that or the objects that knows how to actually do a query to the database so with that just a few lines of code you can get set up so you've opened the channel now you have a way of talking directly to your database I'm going to show you how the sequel command actually execute the sequel slide down so give them an adapter channel there's just one line here that's going to execute sequel your sequel string is just a regular Java string we have to convert that into an expression that an adapter channel knows how to use so we ask the adapter for its expression factory and the expression Factory has a method called expression for string that expression converts it into an expression then we just call evaluate expression on the adapter channel that sends a sequel to the database we get back a result set our results are going to be an array of dictionaries so you can see here what we do set up a mutable array we have to tell the adapter channel what the results said is going to look like I want to take a minute to show you how we specify that I'll come back to that in a second once we've told the adapter channels what the results that will look like we call fetch row multiple times until we get back and null each of those rows of the dictionary we're holding on to our own result set this way and when we're setting up the result set there's one method in the adapter channel called describe results that's the ass after you've made a query to the database the database knows what the results that will look like the adapter channel has a method called describe results that specialized for whatever adapter you have to be using it will create an NS array of EO attributes so if you're doing raw sequel via the adapter channel doesn't know anything about any particular attributes we have to sense the synthesized make new attributes on the fly to describe each of those result columns that are coming back now one thing in normal US operations we never have any name conflicts but we're doing raw sequel your result dictionaries are going to use the column labels that the database gives us in sequel the there's the results are returned by position so there's not any problem with name conflicts but if you're doing some complicated join and two of those columns have to have the same name when we turn that into a dictionary we're going to smash some values because we're going to be using the same tees so I have a few lines of code here just to walk through the result set and change the attribute names if there's any conflicts we can also use that a bit later to manipulate the result set so it's more convenient to use when you want to turn things back into really owes all right so that's enough coach look at that again so now back to the demo this command line tool you can just type sequel to it it executes sit there's a few other commands that knows about in dealing with your model for the demo purposes there's a command that I called mo that's in a load the commands from a text file so that way you won't have to watch me make any mistyped so one reason you might want to use sequel is if you're generating some kind of report you're doing something with sequel aggregate functions or you're doing a complicated query that eos doesn't have a facility or a way of expressing if you're doing in this case we want to get the the minimum value for revenue the maximum value in the average out of the movie table so we execute that we got back just a raw row that's the diction re and then you can see to the labels in each of the results for display purposes I'm just running down the dictionary showing you the keys and the values okay another common thing is fast for a count count stars kind of a special aggregate function in sequel in this case we want to take a look and find all the movies that start with the letter C so we're going to get back just as a result a single dictionary or dictionary single entry that's the count you might do something like this if you want to customize your user interface according to how big the results it is if you just have a few objects we might display it one way if you have millions of objects you might want to do something different okay we're going to come back to this a little bit later I want to show you a bit of a trick way to do this by saying in the normal object world using objects with that's fetch specification this is how you do it in straight sequel alright so now in we fit we figured out what our count was now we want to actually go out and get some bits of the those movie rows in this case I'm asking for the movie ID and for the title that's useful if you're doing some kind of display list we're getting back these dictionaries or not folios we're not keeping any snapshots here but you can put up a display of all the say titles and because you're saving also the movie ID you can convert those back into eos later okay so those are pretty simple sequel examples you probably wouldn't need to execute straight sequel to do that but more complicated query in the eof world is in this case fine find all the movies that have no director I want to take a second go back to you a modeler and just remind you what the model looks like for movies is our basic examples that we have a movie table and it has basically a many-to-many relationship with this with the talent table so any movie could have multiple directors and of course any director could direct multiple movies so when you're modeling that in a sequel relational database you need a correlation table this case we called it director so a director is just a pair of the movie ID and the talent ID that allows us to form the many-to-many relationship I'll go back to our sequel so the question is how do we find all the movies to have no director if you're doing that with a normal set specification well we have to write some code actually an eof we have to get all the movies check each of their directors too many relationships find all all those with the count is 0 and that's perfectly easy to do but if you have a large data set that's going to do a bit of work in fetching all that information from the database and in sequel you can pretty much do that that sort of thing in just one query here i'm doing a sub-query and using the sequel in operator so we want to find out all the movies that have a movie ID where that movie ID does not exist in the director table that's the same thing as saying it has no directors so we can just execute that directly and again I'm getting the title back just for display purposes the main thing if you're doing something else with a neo is to get back that primary key which is the movie idea here alright so that was that was a fairly simple query a little more complicated query you want to find all the movies that have more than one director ok this is a good one for all these sequel experts out there you can think about this a bit I came up with this line of sequel what i'm doing here is joining the director table in the movie table that basically kind of gives me all the director movie pairs then I'm for each of those directors that have directed a movie I'm looking in the director table for anyone else who directed that same movie okay I'm taking account of all those talent IDs where those movie IDs match and that's in a sub-query that I'm that I'm comparing that so I'm saying greater than 1 because I want to find all the movies that have more than one director ok this would be take the same kind of loop if you're just writing regular eof code you have to go fetch all the movies such all the directors and check their account so here we have 6 results again I just fetched the titles new movie IDs now given any primary key of course you can go select the right row here I want to like the movie and given my primary key so 111 let's see what I get this is a raw row now I just I said select star so I don't when I say select star I don't really have much control over the label in that dictionary okay the database is going to decide what labels to use we're translating those labels into the keys for the result dictionary now you may notice that it's using all capital letters that's typical for sequels labels are all caps when I want to turn this back into a movie EO I need to have a dictionary a primary key dictionary that matches the name of my attributes that was used in the primary key so I need to change the key and what I've done here in my little application I've kept a small dictionary where I can do key mapping so I'm gonna say okay whenever you give me a result set map that uppercase movie underscore ID into movie ID that will give me a good result alright so I'm just going to execute that again and you'll see the only difference here that matters right is I have a key here underscore movie ID now another way to do this often is equal if you're specifying your whole select list you can you can say what label to use for any particular column is coming back and so you might just put a label their call it movie ID put it in double quotes so you control the case that way but people have had a problem when they're doing raw rose sequel sometimes they're doing a join they get either name collisions or they get the wrong case on something so in an upcoming update there's going to be a new version of raw rose with sequel that gives you an extra parameter where you can specify the mapping for all those column names that might make it a little easier to use okay so we said we said before we can select with sequel to get things but you can also do a lot of this kind of stuff just in regular us using such specifications so i want to show you here out of how to fetch an object using primary key let me go back to the model and show you a fetch specification alright so in deep fetch one movie this is used to think movies example we're doing a qualifier the space on the movie ID and we have a qualifier variable in this case dollar sign my movie so when you use this specification you need to have a binding for that qualifier variable you can think of this this fetch specification is kind of a template so when you bind something to it you create a new page specification we're using movie ID now if you remember movie ID is the primary key for the movie entity but it let me go back and show you the movie entity movie ID is not marked to the class property okay so that's that's maybe not obvious to everyone but you can qualify over attributes that are not class properties long as they're in your model we know how to map things with your entity alright so we have a simple fetch here we're fetching all enterprise objects let me execute this command EO is a clan that's built into my little tool it basically just called the object of primary key value and does a real fetch in the display here I'm fetch it I have a real movie and we're showing the primary key and I'm throwing all the attributes of course the the advantage to getting really owes is you can use key value coding here I'm going to fetch the that same movie and then you apply the key value coding studio name and it executed that got that EO found the studio which is another AO and then went and got the name out of it so that's much easier than writing all the sequel to go get that particular name now I want to show you another fetch the qualifier variable sorry okay so this one's just the explicit with a deep fetch the V fetch is doing the same thing as my other commanded coming back here I have another such specification this one is a raw fetch specification so I'm getting an attribute called Z count I'm going to take a look at that in a second in how that was modeled qualifier is checking the title so its title like my title my title is gonna be some pattern that we have to bind to now remember we're fetching Z count we're doing a raw fetch so we're not getting back folios we're just getting back a value for Z count and if you look at movie the count is matched that's not a class property so it's not part of your EOS class but it's defined in the entity and our definition for that is count star so we're going to use that sequel expression count star in the fetch specification when we execute it so this is an alternative to using raw sequel and it keeps you in the normal us fetch specification world it's a little bit easier to maintain than executing your own sequel so I'm binding sea star to my title now I'm gonna fetch using that count for title like so I found out that there's five movies on that count and again this is this is a way if you're have to adjust your interface how big your results that is it might make sense you want to go find account first and just to show you if we can fetch those same movies once we have them we know how big it is i'm doing a raw fetch here just to get the movie ids and displaying it alright so that's that's the end of my demo here the what i want to do is get you give you a feel for the fact that you can execute any sequel you want it's good for generating some kind of reports or complicated queries but for other things you want to take a look and try to use objects of that specification when you can thank [Applause] thank you Steve so today we reviewed memory management data freshness optimistic locking multithreading an eof concurrent database access and raro operations I note about the forthcoming webobjects five point to point to update the main focuses of this update is on Mac OS 10 server and j2ee integration particularly jboss but there's some eof impact some goodies here like log4j support and some J&E I look up for your application properties as well as a sorted bug fixing so the apple technical publications group has got tons of documentation and this is the stuff that I use I'm particularly EF developer guide and the 52 Delta doc are both very important and the API reference reporting bugs bug reports apple com if you don't file it we won't know about it probably project wonder lots of interesting extension CEOs as well as just some general idioms already implemented for you for java programming and us programming and some third-party sites the omni group and stepwise sites they've got mailing lists community resources and technical articles both on web objects and on us who to contact web objects at apple com goes to a bunch of people you can also use bug report that up as I calm and there's enterprise level services and consulting support if you want to hire an apple consultant and here's some stuff that somebody else but you should know about you