---
title: WWDC2001 Session 610
framework: wwdc
role: article
path: wwdc/wwdc2001-610
---

# WWDC2001 Session 610

## Transcript

Kind: captions Language: en I wondered welcome you to introduction to data modeling and connectivity and I'd like to introduce Steve miner good morning thank you for coming my name's Steve miner I'm a web objects engineer I don't have any songs for you today like some of our other sessions sorry about that but my mother is Canadian if that helps so it's an introduction we're gonna talk about two major things today first using you modeler to map relational data into java objects and then secondly we will be talking about the JDBC adapter which is our main adapter for web objects 5 so before we get going can I ask how many people have used web objects and use the o modeler before you raise your hand okay so most of you have seen this this is an introductory talk so there might not be that much new for you if you need some extra coffee you can grab it now come back for the second half and find out about JDBC adapter which is new for web objects 5 ok what you'll learn we'll talk about first of all model what a model is how it contains entities attributes and relationships and we'll explain how you how you create those and what they mean then we'll talk a bit about fetch specifications just how you query the database pull objects into your application we'll talk about entity inheritance how to model inheritance some of the pros and cons involved in inheritance and finally we'll talk about the JDBC adapter all right this slide if you if you went to the introduction to enterprise objects framework this slide is supposed to encapsulate that whole hour in one slide ok so at the top we have a database view of the data so that cylinders is a tabular data we have rows and columns in there so we're using a neo model to define how we translate from the tabular data the database into our objects and that's matching up columns into attributes and taking the rows and creating dictionaries first and then into real enterprise objects so the what we're trying to suggest there is we have to do some type coercion to go back and forth from the database native types into the proper Java types and the types that we use in COF and web objects and finally at the end we get the EO and the EO is the enterprise object is what do you want to interact with it'll be living in an editing context and for most web objects applications all you have to worry about is your EOS you're not too worried about your database but we're talking about in this talk how we set up the model to do this mapping so you don't have to think about it anymore once you're once you're writing your application code so what is the neo model well it's if you're familiar with empty relationship diagrams it's a tool that or a model is an object that does the mapping for you it describes both the relational data and the object that you want to transform that relational data into we declare entities which does does a mapping from a particular table into particular objects the connection dictionary defines how you make that connection to your particular data source and we'll talk more about what goes in a connection dictionary later store procedures are also declared in a model there are places where you can use your databases stored procedure to fetch and fetch rows back from the database and crazy owes that way or sometimes you might want to be doing delete or some special logic that's already been encapsulated in your database you need to use that because whoever controls the database doesn't want to give you direct access to the tables and finally we have names fetch specifications so models can can contain pre-built fetch specifications and if you went to the introduction to COF talk you learn more about fetch specifications we'll talk about how our you modeler tool can help you create those fetch specifications you already know how to use them if went to the other talk and we have a lot more information in our documentation about using fetch specifications alright so for our first demonstration we're going to bring up earnest Kim and he'll be running you modeler just to give us a view of our sample data so for this first view we're showing a diagram view we'll get into more details about iya modeler in a minute but just to give us something concrete to talk about we've created a very small database just a few entities in a few relationships ideas here is we have a course entity which represents a course that someone's teaching in school there's some professor who's the instructor for that course and then there are students who are enrolled in the course this diagram view is showing first of all the different entities which are in the boxes the attributes that belong to those entities and then the arrows are suggesting the relationships between the different entities and there's a lot more you can do in the diagram view you can control which things are labeled which attributes are being viewed there's different ways you can filter this and save layouts but for our purposes right now I think this gives you a general idea what we're gonna be talking about and when we do something concrete you'll understand that we just have a few entities involved there's also some inheritance this person is really an abstract superclass or an abstract entity that some of the other entities the student and professor are going to inherit from we just want to show you that for inheritance system this might not be the way you design your school administrative system but it'll give you a suggestion of what you can do in your modeler so what is a neo entity well at the basic level we map a table into the class so you have a database with your rows your rows and columns and you have a Java class you have to declare how you take that raw data and turn it into a neo and UF does all the work for you so there's various aspects and settings you can put on an EO entity first you can market abstract abstract means that you're never going to actually instantiate an object of this class it's just there principally for inheritance there can be a parent entity again if you're using inheritance one entity can inherit from another it'll get all the attributes from the parent entity the restricting qualifier allows you to filter the rows from particular table when you're fetching your entities so we also use this too when we're modeling inheritance basically instead of saying my entities are every row in this table we put some kind of qualifier on that and it restricts it to a subset of those rows we'll talk about that and during the demonstration you can also mark an entity as read-only depending on your application that might speed things up a little bit that means we'll never be writing anything to that entity it's really just there for some kind of bookkeeping purposes you've already pre-built everything and you can cash in any that will that change the behavior of EOF a bit where we know we have everything in memory that we need we can do searches in memory instead of going to the database all time but the last two are used just in special circumstances in general you'll your entities will not be read only it won't be cached and you'll be wanting to write data back to the database all right so let's go back and look at you a modeler and we'll take a closer look at enemies so this is the way we typically open up your modeler and the model name is at the top left of the tree view then we have a list of entities down below over to the right we have a table which declares the entity names what table it goes to and what kind of class you want to instantiate and by default we'll give you an EO generic record which is our convenient folder of data has no particular business logic in most of your applications you'll be creating your own special class to hold your EOS and you'll have some business logic associated with that click ok so now we've selected the course so in the in the course you can see a list of entities and relationships aside we'll talk about those more in a minute I like to browse some data so butters just say you clicked on the icon that looks like a database cylinder with a little magnifying glass on it so it's browsing data this is a good way just to test that your data is there you set up your model it's a it's a immediate validation that that things look right for talking to your database and you can see what kind of values you have in database here you can also just for your convenience you can have a qualifier and filter this list so if you have a lot of data and you just want to take a look see what's in there you might do some experiments here so Ernest is adding the qualifier title like F star so stars wild card so now we see there's only one course in there formal logic which matched that F star you can wipe that out have an unqualified query and we'll get all the classes so for our demonstration here we're only using two classes very small database let's show the inspector on the class so this is a the first panel there's multiple panels in our inspectors and it really pays for you to spend some time playing neo modeler make sure you go to the inspector on all the different types of model objects there's lots of settings you can change in the different inspectors and it's worth spending a little time experimenting and getting to know what all those different things mean so in this first panel we have the name the table name class those are all immediately available anyway in the table view and then we have a list of the properties and this is just another way of editing you can do all this work in the table view also we'll talk about the different properties a bit later so now we're looking at the professor entity and we're looking at the second the second panel advanced entity inspector and this some entity uses inheritance so the first thing you can notice is in the parent box we've selected person and there's a little mark there indicating that the person is the parent for the professor those other all your other entities will be listed here and only one of them will be selected as a parent or maybe none if you have no parent and then the other thing is because of the way we're setting up our table with single table inheritance which we'll talk about later we have a restricting qualifier so when we fetch the professors out of the database we're going to be hitting the person table and we're only we're only interested in rows that satisfy this qualifier where P type equal one so an EO entity contains first of all a whole list of yo attributes and each attribute is mapping a column into an instance field of your Java object or an Ivar if you're used to the objective-c now you have several aspects to a neo attribute the first thing to consider is whether or not this attribute is a class property a class property of your EO means that when we fetch from the database we want to fetch this and create it create a corresponding value in your EO for that column or for this attribute if it's not marked as a class property it's there so that we know what to do when we're generating sequel but it's not declared as part of your class and many many things that you've put in there especially a foreign keys you wouldn't want our primary keys you wouldn't want to mark as a as a class property because it doesn't really contribute to your business logic you're not going to be using that value when you're programming or creating your EOS but yo f needs the primary keys and foreign keys for one work creating sequel and doing some of the bookkeeping for you when we write values back to database so those attributes are declared but they're not marked as class properties the next one is a primary key a primary key is a special attribute that uniquely identifies this row in the database or this AO in your editing context we use the primary keys when we're creating what we call a global ID so that we can will always know how to get to that yo again and again when we're doing faulting we need to know that that primary key so we we know when we need to get this object we'll be able to go to the database and fetch it the next aspect is allows null and this is corresponds directly to what the databases allow you to do you can mark an attribute whether or not it allows null if it allows null then if you don't set it we can write a null into the database in some cases you don't want to allow know you want to insist that your user is set a value there or that your application logic depends on having some value in that attribute so you mark it you leave it off so it doesn't allow null the external type is the type that the database is using it's a type name that's that's specific to a database so Oracle might have a varchar' to in not every database uses that term for the external name so we need to know those external names for when we're creating tables for you.most most of the time if you've done reverse engineer you don't have to worry too much about the external name but if you're switching from one database to another your set of external names might be different and it it's worth knowing what database you're talking to you so you get those external names right and you understand the details about the meaning behind different external names not every database treats even the similar terms the same way the value class is the class that you want this attribute to be expressed as in your EO so when we talk about a varchar' in the database the external type is varchar' in your EO typically that would be a string so we have mappings from most of the common value classes we'll declare something number and map it to the appropriate number the value type is the other column that helps us determine exactly in the case of numbers exactly what type of number to instantiate so that might be a small I'm meaning integer some things are ambiguous if we just are saying we're mapping to number we need to create a concrete class of number and the value type will help us do that there are also a couple of other cases where the value type is special meaning to a particular adapter but maybe maybe these things are attributes aspects of attributes that you use less often you can mark an attribute read-only that means you don't intend to ever modify it and we will you F will raise an error if you do try to modify it you can have custom formatting so you can have special format strings that define how you how you get the values in and out of the database I think this is used less often but there may be some special cases where the values were formatted in a strange way and you really want to store and retrieve things slightly differently a derived attribute is almost a whole another kind of attribute instead of mapping just directly to some column in the database you can have a sequel expression so when you're fetching you can have some combination of logic that is evaluated at the database and we pull the value out of that now usually we can't update that value so if you have some kind of attributes a salary which is multiplying some monthly salary by 12 you could have a sequel expression monthly star 12 and we'll fetch that for you and do do the calculation on the database side so there can be an advantage there or or if you need some special function that exists in sequel that is inconvenient to program in Java you can do that with a derived attribute flattened attributes are attributes that belong to a different entity but we've crossed the relationship to get to this particular attribute and we want to think of this attribute as belonging to our AO even though in our model we've actually we're actually storing the value somewhere else so when we see more about relationships we'll see how that fits in but you can imagine an alias that we've crossed one relationship we're getting the value out of another table but we're storing it and treating it in our Java object as if it were directly part of that so it's it's a way of changing the model to fit your application logic even though your database layout may be a little bit different and custom value class is a capability for mapping the raw data from the database into some more sophisticated object that isn't well that is defined by you and your application is not one of our standard objects such as string or a number it's something that you're defining you want to do mapping from our raw data into that we're going to talk about that more in a minute after the demo all right so let's go back to yo modeler and go back to the computer okay so we want to talk about attributes and we'll review some of the terms here so we've selected person and we see just three attributes the first thing the first column in the attribute viewer is a little key icon I'm not sure if that's clear to everyone out audience the key indicates that this is a primary key and so we're using person ID and this is pretty typical I think that you'll have some kind of number and/or an integer as your primary key it's not a it's not a class property so the second column is that diamond is indicating which things are going to be mapped directly into my ear what things can I use for my business logic in this case the person ID is really an artifact of how we store data in a relational database it's not something that you need typically to worry about in your business logic so we won't mark that as a class property the next column is the locking bit this this determines when we're doing optimistic locking when we made an update or about to make an update to the database what values do we want to check to make sure nothing's changed and that we're safe to do this update so EF as you probably have heard from from the introduction to enterprise object frameworks on Tuesday keep snapshots of all the data that we fetch out of the database and things that are marked for locking we're going to check when you do an update we're going to check that all these other things that you marked for locking are still the same value in the database if someone else had changed that row in the database and we're about to update it our update will fail because it's optimistic walking and that is determined by which attributes you care about and most of the time you want to lock on all your attributes because you want to be safe and make sure that your application is only writing data that it fetched and it in complete control of the database there may be some attributes that you don't want to lock on particularly blobs or any kind of large object it's very expensive to compare those it turns out we can't generate sequel to do the comparison for normal attributes in our where Clause will generate the sequel and make sure that we're we're updating the right row for you but if you have something that's a blob a large kind of object in your database uf is forced to pull that all into memory do an in-memory comparison of that blob and then do the update to be safe and you don't normally want that it's really bad for performance so if you have anything that's large I would say don't mark it for locking all right then we talked about the value class and the first so we're string and number number in Java is abstract so we have to say something more particular about what number to instantiate so the value type in this case we have a little little eye meaning let's transfer this as an integer and we're inheriting this concept really from our objective-c days where we needed we needed more information here we're still doing the same kind of thing and our models we're still storing some objective-c information even though we're doing pure Java for our use the external type we talked about so we have two examples of our char and the number this is this is going against an Oracle database so the varchar' two is the oracle normal type to use for varchar' some different depending on your type you might have a width or you might have a scale and a precision there'll be other columns you can fill out for those just just for your information when people first look at modeler sometimes they don't see everything they want to see about particular aspects of the attribute there's a little popup menu down there to the left this controls what you see neo modeler so as you can see we can we can let's show allows null okay so now that column there with the zero is allowing the column you can make that disappear if you don't want to view that usually you've setup allows no you don't need to look at all time if you hit the Delete key when that column selected it's being hidden we're not we're not taking anything away we're just hiding it from you when you're first using you a modeler sometimes this is a bit confusing since your model looked one way and you've done some some things to rearrange it it might not come back the same way you expected or you might not be able to find things if you get in that situation use the pop-up or use the inspector most of most of these values are available in the inspector alright so we talked a little bit about the custom value class that's another aspect to an attribute and what this does is Maps your your value into a particular class so this is at the attribute level this is just a value in the attribute this is not talking about an EO this is just a custom class for holding some value of your attribute so if you if you're doing this you need to have a factoring method so in in this is an example it might be called if your class is called custom you might have a factory method called custom width string the idea here is a string will be pass this is a string that we've pulled out of the database we're passing it to your method your method will give us back one of your custom objects so you'll you'll just map this in the inspector you need a conversion method so when we're writing things back into the database we have your custom value the UF doesn't naturally know how to put that into the database you'll tell us to use your method in this example custom as string we will send custom a string to your object your object has to respond to that and give us back a string then we know how to put the string in the database for you and the third aspect to a custom value class is the knit argument for the knit argument we've been doing an example where your knit argument is a string it could also be an NS data if you have some large raw data we've but Dennis data or Java byte array alright let's talk about relationships a relationship basically map's a foreign key into another object and we saw earlier how relationships were formed we did we described them in our diagram view as arrows from one relation for one entity to another you've probably seen in other talks where you mat map up match up a foreign key to a primary key in another table when we talked about relationships we're talking a neo F about a one directional relationship so we say two one or two many a to one is a relationship where the destination is a single object so in our example a course might has an an instructor so the course has a 2 1 relationship to the instructor there's just one instructor for our course a too many relationship is where the destination is actually an array of other objects in our example a student might take might be enrolled in multiple courses or a professor might teach multiple courses in those cases we'll create the array we need to know the destination type but we'll create an array of those objects for you and typically UF works well if there's an inverse relationship so something going back the other way there's there are several places where EF wants to figure out how to make an update going back to the the from the destination object into the source object and it's pretty natural when you're modeling things to think of some of these relationships as a pair of one-way relationships so you have an inverse for most relationships but that's not required so we have a little diagram here where you can see the course has one instructor the the doughnuts are the EOS and I think that's that's very common no taste graphical notation in our documentation the arrows represent the relationships the little box of two things is is an NS array and you can see how the course is now the advanced relationships um some other aspects you can set on a relationship the first thing to think about in your relationship is is this optional or mandatory do you require to have a fully-formed do do you require that it has some connection across this relationship does there have to be a destination value or can it be null if it can be null then it's an optional relationship if you require that there's some value there for your business logic and just for your the semantics of your application then it's mark mandatory and EF will enforce that if something's marked mandatory and for some reason your code or your user doesn't set a value there EF will raise an exception propagate primary key is another aspect of a relationship and what what this says is that when you're inserting a new object at the destination of this relationship it can inherit a primary key value from the source object now this is something you have to think about typically you want your objects to have independent primary keys but there are some cases where it's very convenient to propagate the primary key especially when we're doing some kind of correlation table and setting up a many-to-many and we'll show that in our live demo the delete rules tell tell us what to do when you delete an object there are a couple of different possibilities we'll talk about those in a minute when we're showing the live view modeler but you can imagine what one possibility is just the Cascade the delete if you delete a source object you want to follow that relationship delete the destination object and so on another possibility is to nullify so you could if you're deleting the destination object the source object just wants to get a null marked where that relationship used to be owns destination implies a stronger bond between the source object and the destination object in fact it's so strong that there's no if the destination object is not part of this relationship it has no reason for being and it's going to be automatically deleted this can be very convenient in some of your to keep you from having to write too much business logic if if you set a new value for the destination of some relationship the old value will just go away without any extra code on your part if you've marked the relationship owns destination but there are other times where you don't want to do that you don't want to automatically delete things you want to control that let that object live for some other reason and finally batch faulting now we haven't talked about faulting but if you've gone to any of the other AOF talks or maybe some of the other web objects talks you may know about faulting already and if you've used most of you I think have used web objects so you understand the idea of faulting is a fault is kind of a placeholder object when we fetch the objects to begin with they all they have relationships to other objects we're not going to fetch all those objects and recursively load up the whole database into our an in context memory what we do is we fetch the objects that are immediately desired from the fetch specification then for the all the relationships we've put in place holder objects which we call faults when you touch a fault it will magically become the you that you want to use so your business your business logic doesn't have to worry about faults but when we're creating these objects it's important that we Mark there mark especially as faults and there's some performance issues about pulling in the faults if we touch if we touch a fault we have to make one round trip to the database to bring the values back it turns out it's very common that when you touch one fault of a certain type your application typically might touch several other faults of that type so to make that perform better we have a concept of batch faulting you can set on the relationship how many of these faults you want to bring back at once we'll make one round-trip to database and maybe you've marked it for 10 as your batch faulting it's kind of a hint to us okay if you hit this fault bring the next 10 with you and that will improve performance in many cases alright let's go back to you modeler and we'll take a look at some of the relationships we have defined in this model selected student we have a lip a list of relationships here first advisor is a to one relationship let's inspect that so in this in the inspector we can see the destination entity is marked as professor it's marked as a to one and the joins tell us which columns or which attributes were going to use to match up those values and you can see how that maps directly into the sequel we have to generate for a21 the foreign key we the source object holds a foreign key into the destination object so at the destination side is typically the primary keys what you want to join on all right so now this is showing too many the destination is enrollment enrollment is really a correlation table there's not that much interesting about enrollment but it's a way of forming the many-to-many relationship between students and the courses they're taking so our purpose here is just the form that we want to form the too many we're gonna use this to flatten another relationship on the student side the source for the join is the person ID and destination side is a student ID so the enrollment if you think about when we saw the diagram to you the enrollment had a 2-1 relationship the inverse of this was back to the student so this is a little bit simpler we have a definition it says to enrollment dot to course so what we're doing is we're following the first relationship to the enrollments that will get us to an enrollment object that an enrollment object has another relationship to a course by doing this flatten relationship we make that jump to enrollments to course and now the too many relationship is actually an array of courses for this student so when we're modeling this what we cared about were the courses we didn't want to think so much about enrollments they're they're really just to form the correlation table the to map correctly into the relational database but at our object level we want to we want to program and deal in courses directly from the student okay we want to change gears a little bit now and we've talked about what's involved in a model now let's talk about how you create a model and tables so the EO modeler tool can do what we call a reverse engineering reverse engineering is a way of interrogating the database finding out what tables already exist and creating the proper entities and mappings for all the attributes we do that automatically for you it's a good starting point many in many applications you already have your data someone else has defined the data for you and you're going to put a web interface on that so you want to get access to the database tables reverse engineer maybe you don't need all the tables you'll pick a list of the tables you want to use and let UF crate or modeler create those entities and attributes that's a good starting point after you've done that you'll want to go inspect your model maybe you don't need all the attributes you'll take some out maybe you'll need to form some other relationships you might want to flatten some relationships there's quite a bit you can still do after you vers engineered but it's a good starting point it saves you from having to type a lot of detail that you already know and already been declared in the database now not everyone wants to go in that direction for some applications you're in charge you're you get to define the data format so you might start with neo model and experiment a bit you just create some entities declare they declare all the information need all the things we've talked about especially the attributes and the external types and ego modeler will generate the sequel that's necessary to create those corresponding tables we'll show you that in a minute you modeler can also create Java source code for you so you've declared your entities all your attributes your entities are going to correspond to a particular class that you want to use for business logic your attributes map into the instance fields that class will create the basics of the Java source typically you'll start with that and then add more business logic and then the other aspect of iya modeler has a feature called schema synchronization so a schema synchronization it's a way of map matching up what's in your database to what's in your model and vice versa it gives you some options about what to do with missing fields or additional fields it's a way of synchronizing your model with your database so editing a model the typical things that you might want to change in a model first of all switch adapter so you've done it you've done your application you've used one kind of datasource let's say you started with open base and for some reason you want to change you have another database server an Oracle server you want to use switch adapter to modify your model to work with your new data source in particular when you do switch adapter even if you choose JDBC which we'll talk about later switch adapter will work through your model all your attributes fix up your external types to map to that particular datasource this is important in our previous releases people we'd have separate adapters an Oracle adapter or Sybase adapter now we're going to be using one adapter but the mechanism for adapting or changing your model into a new data source is still to use switch adapter said adapter info is a simpler operation at this point you're just editing the connection dictionary you're not going to make any other changes immediately to your model so this can be a little bit confusing when we're using JDBC we'll talk about that in a minute if you if you change your if you just use switch adapt if you use set adapter info and change something that's significant about your datasource it would be better to use switch adapter to make sure that everything in your model gets changed and of course when you're editing a model as we've seen there are lots of fields that you can change you make all your changes to your attributes and your entities just use um audit or click on something type something else over it that's how you make change and use the inspectors there's sometimes more information available in the inspector than we can show in the table view so that's another way of changing information about your model and the final bullet is editing fetch specifications we have a fetch specification builder built into you modeler you can associate fetch specifications directly with an entity given a name then that's available to your code at runtime and it's very easy way to fetch other objects you've already set up a fetch specification or a template for a fetch specification you can use qualifier variables to fetch particular information that you want so we'll look at the fetch specification builder in a minute okay let's go back to you modeler so as we mentioned for tables we wanted to we have course selected we want to show the sequel generation panel a little sequel button well yeah we'll turn off those two about dropping tables but we're going to slide down here you can see we've generated some sequel to create this table for you and then we're also generating some sequel in this case to go against Oracle to create a sequence so we can create primary keys using that sequence and we have a little code here that's trying to figure out what the next value should be in that sequence in case you already have data in your database we're not going to do it now but you can there's a button at the bottom that says to execute the sequel that would go create the table we already have the table if you already have a table created Oracle will give you some errors they're pretty soft there so you can just continue past that the tables button is a convenient way to check what's already in my database and if you've just if you wanted to create something you can see it kind of reinforces that things worked correctly if you click on that table button and just get your list when you're dealing with Oracle of course these tables belong to the particular user that logged in different databases will have different ways of deciding what the tablespace is okay so that that gives you a general idea of what you can do for creating and we talked earlier about reverse engineering tables all right let's get back and talk a little bit about ego FET specification so you use a fetch specification when you want to get data out of your database and create a OS it fetches objects from the database into your editing context by using by filtering according to the eyo qualifier that you assign to your fetch specification and the u qualifier I think you've seen in the introduction to UF how you form a neo qualifier it's a query language that's a simple kind of object-oriented you can use key value coding have key paths involved in your qualifier so we'll the joins and across multiple tables for you automatically you don't have to think too much about where all your data is located just work at the object level crossing relationships and referring to attributes by their key name one thing you can set on a fetch specification is the notion of is it deep or not and this has to do with when we're using entity inheritance a deep fetch fetch specification will fetch not only the entity that has been assigned to but also all the sub earnings so in our case we have person as as the parent class for professor and students so if you try to fetch person will fetch all the all the persons will fetch all the professors and fetch all the students and then we'll filter according to whatever your qualifier is we also use fetch specifications for shared objects in the EO entity inspector you can see where you can mark whether or not you want to move objects into the shared editing context when you first load up this model I think we'll talk about this in the advanced the u.s. session later today I think that begins at 3:30 so if we're if you're using shared objects you'll you'll want to use a named fetch specification you might want to share all the objects of this entity or you might want to filter that and use a fetch specification just to get certain objects moved automatically into the shared edited context and finally we have inside iya modeler there's a fetch specification builder and we'll take a look at that select professor little plus the little plus sign there expands the professor you can see all the relationships below it and the stored procedures so sort procedure has a slightly different icon if I click on that we're showing the fetch specification builder and we have a we have a fetch investigation already there we want to brow let's browse data and see what we get back so this was a very simple fetch specification we just wanted to see all the professors whose name began with J so we can change that easily we'll close that if you want to you can edit that let's say wanted W you can put whatever you want in there and go browse again this is an easy way to test your FET specification right there in the Builder let's take a look at some of the other tabs in the fetch investigation builder we talked about that specifications and some of our other UF talks the sort ordering allows you to choose how your results are going to be ordered so you might order by name in this case office location whatever you can you can choose several of these different attributes and we'll order on those you can even follow a key path and we'll order according to the results in that key path the next tab is prefetching now the idea here is when we're fetching some objects with a fetch specification there are some related objects that we might know because of our application logic that it were likely to touch these other objects so I told you before that normally when we fetch an object we create a fault for the relationships if you're setting out if you set up prefetching you can say well I really know I'm gonna need that object so don't just make a fault on some of these objects we want you to prefetch we want you to go get the real object so we have that in memory as a result of this one fetch we might actually have to go to the database a couple of times but we can group things and give you bit better performance if you have a prefetching turned on for things that you actually need and that again would be following some kind of relationship and saying get me that object at the end of this relationship whenever you fetch this fetch specification the next panel is called raw fetch so this is a little different spin on our fetch specifications normally we're always fetching AOS for you we're doing a lot of special work for you to do the bookkeeping so you can update those iou's well matically save all your changes to the database some of that bookkeeping involves a bit of overhead and for some particular uses you just want to get the raw data or maybe you have so many rows in your database that you don't necessarily need all the iou's at once you want to get just the primary keys and in our case a we had thousands of thousands of courses we wanted to fetch just the primary keys for those courses and the titles we might create some kind of list that our user will take a look at and when the user selects one of them then we then we would take that that raw result and turn it into the real you so the idea behind the raw result is we've fetched a dictionary for you that is not any oh it hasn't it hasn't been unique it hasn't been assigned global ID and we're not doing any snapshotting at this point if we're fetching raw or just giving you the data in a way that's convenient for you to use it then we have other methods that you can call on that raw dictionary and turn it into a fault or turn it into a real object when you need to use it so this can improve performance in cases where you have a large result set or some other cases where you don't need any special business logic you just need the raw values and there's you can decide which attributes to fetch we have a couple of choices there whether we fetched all of all of the attributes as raw rows or we just fetch a certain set of the attributes these are all rows but the usual thing is most of the time you want to fetch enterprise objects and have a Oh F do the special work to keep track of those objects for you so you don't have to think about updating your database you just change the object Save Changes and everything happens magically the next panel options alright so there's a couple of extra options you can set on a fetch specification first thing is the fetch limit how many rows you there might be a case where you only want to get so many rows you're not sure how many are out there but let's stop at some limit when you're doing desktop applications that makes sense to prompt on a limit you might pull back the first hundred rows and let the user decide I'll get the next hundred these other things about doing deep inheritance fetch fetching distinct rows basically adds distinct when we're generating the sequel we'll add a distinct so you don't get duplicates in your result set we can lock the objects I don't recommend you use that but if you're especially if you're doing a desktop kind of application you really know you own the database you can lock the database the objects in the database whenever you fetch them if you're doing a web application you don't want to do that it's in a hurt performance and it'll cause you other problems so don't don't lock your fetch specifications in general but if you know that you need it it's there refresh refreshed objects so usually if EF has already has an object and you do you run another fetch specification getting back that same object yo F won't do anything special because it says we already have that it's in our cache if you set this then what you're telling you app is well when you when you fetch this fetch specification for me even if I've already seen these objects and think I know about them I want you to refresh them give me whatever's in the database instead of what I already have in memory and finally require all variable bindings we didn't talk so much about variable binding and in the other introduction to you F talk they discuss variable bindings but you can set placeholder variables in your fetch specifications so they're not fully formed at this point but you're going to do a binding using your code you'll set up a dictionary to bind those query or qualifier variables and create a new fetch specification at runtime so that can be really convenient to use the fetch specification as a template for other other fetches that you want to do okay and then the final panel is a sequel panel in this case we can see the raw sequel that's going to be generated you can decide for a complicated fetch specification you could say well you know I could optimize that I could I could write better sequel than EOS so if you if you can do that then you say use the raw sequel expression you give us an expression it has to return the result set the same way you F would I don't recommend you do this unless you really know that that you can get the best results and it's and it's much better than AOF can do this is hard to maintain when you change your objects uf will do the right thing with all your fetch specifications but you know your raw sequel won't won't know the difference and you can also mark stored procedures to use to do your fetch instead of doing sequel at all you might call stored procedure all right we need to talk quickly about inheritance there's three kinds of inherits we're talking about entities that are inheriting from other entities as we've already indicated in our example we have a generic person and then professor and student both inherit from person so vertical inheritance for vertical inheritance at the database level we're mapping all the columns that are common into the superclass so we have one table for person which is holding the person ID in the last then we're creating for a professor which is a sub entity a person we have another database table the professor table it has just the attributes that are special to professor it also has to have the same primary key so we can match those up and do a join but what's special for professor is that he has an office student what's special about a student is he has this advisor ID in the database we're going to use that as the foreign key to map to our adviser object so for vertical inheritance which is kind of the most natural if you're coming from an object-oriented point of view everything that's common is in the superclass and then things that are specific are mapped to specific tables we have to do a join to create a real EO so when we want to fetch a particular professor we have to fetch the parts of the professor that are stored in the person table and then the parts that are stored in the professor table join those up to make one EO for the professor another way to do inheritance is to push those common attributes down into the other tables so at this point we call it horizontal inheritance we've taken things that we're vertical push them down into in this case the professor table now has everything associated with a professor so here's the person ID the last name and the office all in that one table so now if we're fetching a professor we only have to fetch against that one table okay if we're fetching a student we have a separate student table his person ID last name those were the common parts and then he has a special advisor ID again it's in that one table if we're doing a deep fetch on person which is in this now Adana marked person abstract we might have had persons that were in abstract and are in our example persons abstract so we don't have to worry about actually hitting a person table if if you might have generic persons then we'd have to fetch against that table first then we'd have to fetch each of the sub entities individually and join all those results back to do a deep fetch so that that again could be a bit slower a special case of inheritance is what we call single table inheritance in this case we make one database table with the union of all the attributes that might be anywhere in this hierarchy by doing this we can we can fetch we can do a deep fetch by using one select statement against the database table and then then uf has to figure out as we're pulling rows back well is this a professor is this a student maybe this is a generic person we can do that one select pull them back and figure out which ones they are give you a result set so if you're doing inheritance and you don't have too complicated of an inheritance hierarchy I recommend you see a single table inheritance for performance reasons you will have to leave some columns null right because the student even though the student as a row in the database student doesn't have an office so that would have to be null for that student so you need to have a little bit of flexibility in how you're defining your table in order to make single table inheritance work we've also added an extra column called P type that's special for single table inheritance we're using P type to declare exactly what type of value we have in that rrrow so we're using a 1 to be a professor or two to be a student uf needs some kind of restricting qualifier that will that we talked about earlier to know exactly how to create the right kind of a year for you okay we're down to go back to a demo and I think we have to be very brief here okay I think actually since we're running low on time I want to save time for questions so we'll just show this to you quickly and then I think we'll end after that so we can see here Ernest has brought up two different viewers on the same model and you can see person has the common types just like our graph the student has a one extra attribute advisor the other the other things that are common to the superclass are actually the other attributes are written in a tower type to suggest that you're inheriting these from the person so let's just inspect student and so in this inspector the important thing is we're strict and qualify our P type equals two that's how we distinguish we're in single table we pull an individual row out what kind of vo should we create we're gonna use that P type equal to restrict and qualifier to know this thing is a student it's not an actor person it's not a professor and you can see the parent was marked as a person so that's how we're determining what we're inheriting from you only had to add the advisor you didn't have to declare all those other attributes so maybe we can just let's just browse person and that will finish it so if we browse data per person you can see everything's stored in one database table the P type column is different Worcester and Jeeves are actually professors they're type one and think natl and little our students to their type two okay I think I'm gonna wrap up here there's more you can do with you modeler I'm going to be in the lab after the talk and we'll have other people in the lab all during the day so you can come experiment with models and ask particular questions about how you want to model certain objects we go back to the slides please okay we've run late so I have to whiz through the adapter information the important thing to know is for web objects 5 the JDBC adapter is the adapter this is one we're giving you nice thing about JDBC is it gets to all kinds of different databases we have we have great connectivity because we're using JDBC almost every database vendor is delivering a JDBC driver we can talk to that we've done specific work with Oracle and open base but other things can be added to our JDBC adapter one thing about JDBC just JDBC doesn't really stand for anything it's just a bunch of letters that son had trademarked but you can think of it as ODBC for Java okay so in your connection dictionary the important thing is to set a JDBC URL that's determined by your database vendor or the particular agency driver you're using you need to know the details of that and that can be a little bit complicated we have two examples here of Oracle and open base if you're using some other driver figure out from the documentation how you want to address that our plug-in is our way of adding special behavior that works that particular data source and by default we'll guess it by looking at the sub protocol in your JDBC URL and you can programmatically decide to use certain plugins for our sub protocol name so you have some control of that in your application the driver again will try to guess that if you're using Oracle will guess the right plugin the plug-in will guess which driver to try to load you have to make sure that drivers available at runtime and the easiest place to do that is to put it into your Java VMs X directory so on Mac os10 sir micros 10 that would be in library Java home Lib X and this is documented on different platforms where you can put these things you can put in your class path anywhere just make available at runtime we can experiment with models and if we don't have time for all the questions here I'll be in the lab after this talk so the other the other talks that are coming up today director Webb's right after this the advanced you Enterprise objects framework is a really good talk if you want to get more into advanced topics in the UF you