Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc) » [Teneo] New feature I've written for your consideration / discussion: extended references
| [Teneo] New feature I've written for your consideration / discussion: extended references [message #92917] |
Thu, 09 August 2007 17:05  |
 Jason Henriksen
Messages: 231
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
------=_NextPart_000_002B_01C7DA6C.D8907F20
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hi Martin,
Over the last couple of weeks I've extended a feature of yours. The =
code I have is very experimental, but I wanted to explain the goal of it =
to you and see what you think. Please remember that I have all the code =
I'm about to describe working, but that I want to bounce it off of you =
to see if you might want to integrate it.
Basically, I've extended the anyURI xsd:type that you had previously =
discussed with me. I think this is a tremendously powerful feature but =
I needed to tweak a few things to make it work.
First off consider the url: hibernate://?dsname=3Dmystore&query1=3DFROM =
Writer
This url has two problems: First off, the dsname isn't something we want =
outside users of the reference to see and the query gives move =
information about our database than we want clients to have. The ideal =
reference url is "entity://#<object-type>.<id number>" so for example =
"entity://#Consumer.218". I know you already had a pipe delimited =
version that was similar to the URL that I want, but that code does a =
"select * from table" and then spins though the results. I have way =
more database records then machine memory, so I set up a new URL style =
so as not to mess up any existing functionality. (And my clients =
thought the . was more readable than the pipe, so I just went with it)
So first off why did I change the protocol name: EMF auto-resolves the =
references on the back end where the database is available and that is =
awesome. However if you on the front end with a SOAP interface between =
you and the data base, hibernate is unavailable to you. Thus the =
hibernate protocol is a bit of a misnomer. On the front end, the EMF =
resolver code will be configured to auto-matically make a SOAP request =
to the back end in order to resolve the URL. On the backend the =
resolver will be configured to use hibernate. But since it's not using =
hibernate in both layers, we thought that 'entity' would be a more =
correct term. It also disambiguates my new stuff from your existing =
code a bit.
The next part is the dsname section. This is something I'm still =
messing with, but for the most part I've just set a globally 'well =
known' name that all of the reference handlers use. I'm not sure that's =
going to scale to multi-threaded work, so I'll probably need to have a =
ThreadLocal variable that stores the name. However, the basic idea that =
the xml user shouldn't be able to see the datasource name stands. What =
if the name changes, but old XML gets used? For now, in my low =
contention model, just using a global name set through properties works, =
and if I have to make it more scalable later I can make that work.
Finally we have the "#<object-type>.<object-id>" section. Clearly this =
requires that all of your objects have a unique id number, but I'm happy =
to make that requirement. This URL is automatically converted into a =
query URL which teneo then handles normally. In order to do that =
converstion, I've enhanced teneo to take a user-supplied helper class. =
The default helper class (that we could ship with teneo) simply takes =
the "#Consumer.218" and converts it to the query "select * from Consumer =
where id-column =3D 218". It figures out what the appropriate id-column =
name is by inspecting the ecore package associated with the data source. =
Once we have the query, then I just let Teneo do its magic.
So once all that was done, I could import xml with my new reference =
format and the EMF would auto-resolve the proxy objects beautifully. =
From there I did a bit more hacking and property adding and made it so =
that EMF when writing XML would put out my new reference format as well =
and life was good. I did have to add a bit of EMF code to prevent it =
from asking to load the whole "file" and thus trying to load the whole =
DB again, but those changes were fairly minor.
All this code works and is looking fairly good. If you're interested in =
seeing it, I'll polish it up and send you a patch to consider. I'd also =
love to hear if you have any design ideas or concerns about this plan.
Thanks Martin!
Jason Henriksen
------=_NextPart_000_002B_01C7DA6C.D8907F20
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1561" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2>Hi Martin,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Over the last couple of weeks I've =
extended a=20
feature of yours. The code I have is very experimental, but I =
wanted to=20
explain the goal of it to you and see what you think. Please =
remember that=20
I have all the code I'm about to describe working, but that I want to =
bounce it=20
off of you to see if you might want to integrate it.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Basically, I've extended the =
anyURI xsd:type=20
that you had previously discussed with me. I think this is a =
tremendously=20
powerful feature but I needed to tweak a few things to make it=20
work.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>First off consider the url: =20
hibernate://?dsname=3Dmystore&query1=3DFROM Writer</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>This url has two problems: First off, =
the dsname=20
isn't something we want outside users of the reference to see and the =
query=20
gives move information about our database than we want clients to =
have. =20
The ideal reference url is "entity://#<object-type>.<id=20
number>" so for example "entity://#Consumer.218". I =
know=20
you already had a pipe delimited version that was similar to the =
URL that I=20
want, but that code does a "select * from table" and then spins though =
the=20
results. I have way more database records then machine memory, so =
I set up=20
a new URL style so as not to mess up any existing functionality. =
(And my=20
clients thought the . was more readable than the pipe, so I just went =
with=20
it)</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>So first off why did I change the =
protocol=20
name: EMF auto-resolves the references on the back end where the =
database=20
is available and that is awesome. However if you on the front end =
with a=20
SOAP interface between you and the data base, hibernate is unavailable =
to=20
you. Thus the hibernate protocol is a bit of a misnomer. On =
the=20
front end, the EMF resolver code will be configured to auto-matically =
make a=20
SOAP request to the back end in order to resolve the URL. On the =
backend=20
the resolver will be configured to use hibernate. But since it's =
not using=20
hibernate in both layers, we thought that 'entity' would be a more =
correct=20
term. It also disambiguates my new stuff from your existing code a =
bit.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>The next part is the dsname =
section. This is=20
something I'm still messing with, but for the most part I've just set a =
globally=20
'well known' name that all of the reference handlers use. I'm not =
sure=20
that's going to scale to multi-threaded work, so I'll probably need to =
have a=20
ThreadLocal variable that stores the name. However, the basic idea =
that=20
the xml user shouldn't be able to see the datasource name stands. =
What if=20
the name changes, but old XML gets used? For now, in my low =
contention=20
model, just using a global name set through properties works, and if I =
have to=20
make it more scalable later I can make that work.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Finally we have the=20
"#<object-type>.<object-id>" section. Clearly=20
this requires that all of your objects have a unique id number, but =
I'm=20
happy to make that requirement. This URL is automatically =
converted into a=20
query URL which teneo then handles normally. In order to do that=20
converstion, I've enhanced teneo to take a user-supplied helper =
class. The=20
default helper class (that we could ship with teneo) simply takes the=20
"#Consumer.218" and converts it to the query "select * from Consumer =
where=20
id-column =3D 218". It figures out what the appropriate id-column =
name is by=20
inspecting the ecore package associated with the data source. Once =
we have=20
the query, then I just let Teneo do its magic.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>So once all that was done, I could =
import xml with=20
my new reference format and the EMF would auto-resolve the proxy objects =
beautifully. From there I did a bit more hacking and property =
adding and=20
made it so that EMF when writing XML would put out my new reference =
format as=20
well and life was good. I did have to add a bit of EMF code to =
prevent it=20
from asking to load the whole "file" and thus trying to load the whole =
DB again,=20
but those changes were fairly minor.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>All this code works and is looking =
fairly=20
good. If you're interested in seeing it, I'll polish it up and =
send you a=20
patch to consider. I'd also love to hear if you have any design =
ideas or=20
concerns about this plan.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Thanks Martin!</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial=20
size=3D2> &nbs=
p; &nbs p; &nbs p=
; =20
Jason Henriksen</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV></BODY></HTML>
------=_NextPart_000_002B_01C7DA6C.D8907F20--
|
|
|
| Re: [Teneo] New feature I've written for your consideration / discussion: extended references [message #93224 is a reply to message #92917] |
Fri, 10 August 2007 22:26  |
Martin Taal
Messages: 5468
Registered: July 2009 |
Senior Member |
|
|
Hi Jason,
See my comments inline.
gr. Martin
Jason Henriksen wrote:
> Hi Martin,
>
> Over the last couple of weeks I've extended a feature of yours. The
> code I have is very experimental, but I wanted to explain the goal of it
> to you and see what you think. Please remember that I have all the code
> I'm about to describe working, but that I want to bounce it off of you
> to see if you might want to integrate it.
>
> Basically, I've extended the anyURI xsd:type that you had previously
> discussed with me. I think this is a tremendously powerful feature but
> I needed to tweak a few things to make it work.
> First off consider the url: hibernate://?dsname=mystore&query1=FROM Writer
>
> This url has two problems: First off, the dsname isn't something we want
> outside users of the reference to see and the query gives move
> information about our database than we want clients to have.
MT>> Yes I agree that it is nicer to hide the name and the query. Probably dsname can be hidden as
most apps will only have one datastore anyway. So this can be solved by letting HbHelper return the
default (single) datastore which was registered earlier.
The ideal
> reference url is "entity://#<object-type>.<id number>" so for example
> "entity://#Consumer.218". I know you already had a pipe delimited
> version that was similar to the URL that I want, but that code does a
> "select * from table" and then spins though the results.
MT>> I am not sure what you mean, the code in getObjectById does a query on the id
and does not iterate over the complete dataset.
MT>> use a dot instead of a | is a matter of taste I think, I used | because this was used by jpox
also.
> I have way
> more database records then machine memory, so I set up a new URL style
> so as not to mess up any existing functionality. (And my clients
> thought the . was more readable than the pipe, so I just went with it)
>
> So first off why did I change the protocol name: EMF auto-resolves the
> references on the back end where the database is available and that is
> awesome. However if you on the front end with a SOAP interface between
> you and the data base, hibernate is unavailable to you. Thus the
> hibernate protocol is a bit of a misnomer. On the front end, the EMF
> resolver code will be configured to auto-matically make a SOAP request
> to the back end in order to resolve the URL. On the backend the
> resolver will be configured to use hibernate. But since it's not using
> hibernate in both layers, we thought that 'entity' would be a more
> correct term. It also disambiguates my new stuff from your existing
> code a bit.
MT>> I like entity also, in fact you can choose any protocol. The protocol is only used by the
ResourceSet to determine which ResourceFactory to use. You can register your own protocol to
resourcefactory in the resourceset.
>
> The next part is the dsname section. This is something I'm still
> messing with, but for the most part I've just set a globally 'well
> known' name that all of the reference handlers use. I'm not sure that's
> going to scale to multi-threaded work, so I'll probably need to have a
> ThreadLocal variable that stores the name. However, the basic idea that
> the xml user shouldn't be able to see the datasource name stands. What
> if the name changes, but old XML gets used? For now, in my low
> contention model, just using a global name set through properties works,
> and if I have to make it more scalable later I can make that work.
MT>> Many applications only work with one database. This means also one datastore.
So instead of trying to store a dsname in a thread local I would opt for a change
in the hbhelper so that it returns a single (default) datastore.
>
> Finally we have the "#<object-type>.<object-id>" section. Clearly
> this requires that all of your objects have a unique id number, but I'm
> happy to make that requirement.
MT>> Yes this is a safe assumption.
> This URL is automatically converted
> into a query URL which teneo then handles normally. In order to do that
> converstion, I've enhanced teneo to take a user-supplied helper class.
> The default helper class (that we could ship with teneo) simply takes
> the "#Consumer.218" and converts it to the query "select * from Consumer
> where id-column = 218". It figures out what the appropriate id-column
> name is by inspecting the ecore package associated with the data
> source. Once we have the query, then I just let Teneo do its magic.
MT>> Hibernate and jpox both offer methods to do get(EntityName, id) so then you don't need
to identify the id-feature.
MT>> I like the use of a separate helper class which takes care of uri-reference creation and object
retrieval (URIReferenceStrategy or something).
>
> So once all that was done, I could import xml with my new reference
> format and the EMF would auto-resolve the proxy objects beautifully.
> From there I did a bit more hacking and property adding and made it so
> that EMF when writing XML would put out my new reference format as well
> and life was good. I did have to add a bit of EMF code to prevent it
> from asking to load the whole "file" and thus trying to load the whole
> DB again, but those changes were fairly minor.
MT>> Can you give some more detail? The current hibernate/jpox resources already have some specific
iterators which do not load unloaded lazy lists. Let me know if there are other changes required.
>
> All this code works and is looking fairly good. If you're interested in
> seeing it, I'll polish it up and send you a patch to consider. I'd also
> love to hear if you have any design ideas or concerns about this plan.
MT>> Yes I am always interested in contributions, so please send it to me. Maybe I can incorporate
the uri-helper class.
>
> Thanks Martin!
>
> Jason Henriksen
>
>
>
>
>
>
--
With Regards, Martin Taal
Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: mtaal@springsite.com - mtaal@elver.org
Web: www.springsite.com - www.elver.org
|
|
|
| Re: [Teneo] New feature I've written for your consideration / discussion: extended references [message #609460 is a reply to message #92917] |
Fri, 10 August 2007 22:26 |
Martin Taal
Messages: 5468
Registered: July 2009 |
Senior Member |
|
|
Hi Jason,
See my comments inline.
gr. Martin
Jason Henriksen wrote:
> Hi Martin,
>
> Over the last couple of weeks I've extended a feature of yours. The
> code I have is very experimental, but I wanted to explain the goal of it
> to you and see what you think. Please remember that I have all the code
> I'm about to describe working, but that I want to bounce it off of you
> to see if you might want to integrate it.
>
> Basically, I've extended the anyURI xsd:type that you had previously
> discussed with me. I think this is a tremendously powerful feature but
> I needed to tweak a few things to make it work.
> First off consider the url: hibernate://?dsname=mystore&query1=FROM Writer
>
> This url has two problems: First off, the dsname isn't something we want
> outside users of the reference to see and the query gives move
> information about our database than we want clients to have.
MT>> Yes I agree that it is nicer to hide the name and the query. Probably dsname can be hidden as
most apps will only have one datastore anyway. So this can be solved by letting HbHelper return the
default (single) datastore which was registered earlier.
The ideal
> reference url is "entity://#<object-type>.<id number>" so for example
> "entity://#Consumer.218". I know you already had a pipe delimited
> version that was similar to the URL that I want, but that code does a
> "select * from table" and then spins though the results.
MT>> I am not sure what you mean, the code in getObjectById does a query on the id
and does not iterate over the complete dataset.
MT>> use a dot instead of a | is a matter of taste I think, I used | because this was used by jpox
also.
> I have way
> more database records then machine memory, so I set up a new URL style
> so as not to mess up any existing functionality. (And my clients
> thought the . was more readable than the pipe, so I just went with it)
>
> So first off why did I change the protocol name: EMF auto-resolves the
> references on the back end where the database is available and that is
> awesome. However if you on the front end with a SOAP interface between
> you and the data base, hibernate is unavailable to you. Thus the
> hibernate protocol is a bit of a misnomer. On the front end, the EMF
> resolver code will be configured to auto-matically make a SOAP request
> to the back end in order to resolve the URL. On the backend the
> resolver will be configured to use hibernate. But since it's not using
> hibernate in both layers, we thought that 'entity' would be a more
> correct term. It also disambiguates my new stuff from your existing
> code a bit.
MT>> I like entity also, in fact you can choose any protocol. The protocol is only used by the
ResourceSet to determine which ResourceFactory to use. You can register your own protocol to
resourcefactory in the resourceset.
>
> The next part is the dsname section. This is something I'm still
> messing with, but for the most part I've just set a globally 'well
> known' name that all of the reference handlers use. I'm not sure that's
> going to scale to multi-threaded work, so I'll probably need to have a
> ThreadLocal variable that stores the name. However, the basic idea that
> the xml user shouldn't be able to see the datasource name stands. What
> if the name changes, but old XML gets used? For now, in my low
> contention model, just using a global name set through properties works,
> and if I have to make it more scalable later I can make that work.
MT>> Many applications only work with one database. This means also one datastore.
So instead of trying to store a dsname in a thread local I would opt for a change
in the hbhelper so that it returns a single (default) datastore.
>
> Finally we have the "#<object-type>.<object-id>" section. Clearly
> this requires that all of your objects have a unique id number, but I'm
> happy to make that requirement.
MT>> Yes this is a safe assumption.
> This URL is automatically converted
> into a query URL which teneo then handles normally. In order to do that
> converstion, I've enhanced teneo to take a user-supplied helper class.
> The default helper class (that we could ship with teneo) simply takes
> the "#Consumer.218" and converts it to the query "select * from Consumer
> where id-column = 218". It figures out what the appropriate id-column
> name is by inspecting the ecore package associated with the data
> source. Once we have the query, then I just let Teneo do its magic.
MT>> Hibernate and jpox both offer methods to do get(EntityName, id) so then you don't need
to identify the id-feature.
MT>> I like the use of a separate helper class which takes care of uri-reference creation and object
retrieval (URIReferenceStrategy or something).
>
> So once all that was done, I could import xml with my new reference
> format and the EMF would auto-resolve the proxy objects beautifully.
> From there I did a bit more hacking and property adding and made it so
> that EMF when writing XML would put out my new reference format as well
> and life was good. I did have to add a bit of EMF code to prevent it
> from asking to load the whole "file" and thus trying to load the whole
> DB again, but those changes were fairly minor.
MT>> Can you give some more detail? The current hibernate/jpox resources already have some specific
iterators which do not load unloaded lazy lists. Let me know if there are other changes required.
>
> All this code works and is looking fairly good. If you're interested in
> seeing it, I'll polish it up and send you a patch to consider. I'd also
> love to hear if you have any design ideas or concerns about this plan.
MT>> Yes I am always interested in contributions, so please send it to me. Maybe I can incorporate
the uri-helper class.
>
> Thanks Martin!
>
> Jason Henriksen
>
>
>
>
>
>
--
With Regards, Martin Taal
Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: mtaal@springsite.com - mtaal@elver.org
Web: www.springsite.com - www.elver.org
|
|
|
Goto Forum:
Current Time: Sat Apr 20 00:16:13 GMT 2024
Powered by FUDForum. Page generated in 0.03595 seconds |
] 
Search
Help
Register
Login
Home
