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