midgard_guid_new and legacy objects

	Hi!

Problem description:
midgard struct mgd has GObject member ( currently defined as
gpointer 
due to not being cleaned yes header files ) which is a
pointer to MgdObject 
with midgard_person as type. When person do some auth I set
internally 
this object as connection handler's member. This is done to
have  ( always 
during runtime )  every  person's data like guid for
example.

However,  problem appears when you for example create person
with spider
and next you do auth and try to create new type. Simply
there's no guid property
being set for midgard_person object.

We need to create Midgard Lite (M-L) implementation anyway
after 1.8 is out, so 
I decided to add guids and other basic metadata support for
legacy objects.

Advantages:
	* We can still "mix up" old and new types using
any admin UI
	* No need to future special "old" record
updates
	* new fields are added to old objects transparently without
touching objects properties
	* M-L implemenation will be ready for new classes 
	( even if records were created with old API ) 
	* we do not deprecate old API for one release and bring it
to live again in another release

Technically I wil update only mgd_vcreate and mgd_vupdate
functions so we will have new features
basic support for all old classes with one change.

My question now is:

Should I run another two queries when object is created or
updated to get and insert the same guid 
or to tune old guids functions ( make only two queries ) and
make uuid support at the same time?

Piotras

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribemidgard-project.org
For additional commands, e-mail: dev-helpmidgard-project.org

Piotras <ppinfoglob.com> wrote:

Retrying... ;)

 
> 	Hi!
> 
> Problem description:
> midgard struct mgd has GObject member ( currently
defined as gpointer 
> due to not being cleaned yes header files ) which is a
pointer to MgdObject 
> with midgard_person as type. When person do some auth I
set internally 
> this object as connection handler's member. This is
done to have  ( always 
> during runtime )  every  person's data like guid for
example.
> 
> However,  problem appears when you for example create
person with spider
> and next you do auth and try to create new type. Simply
there's no guid property
> being set for midgard_person object.
> 
> We need to create Midgard Lite (M-L) implementation
anyway after 1.8 is out, so 
> I decided to add guids and other basic metadata support
for legacy objects.
> 
> Advantages:
> 	* We can still "mix up" old and new types
using any admin UI
> 	* No need to future special "old" record
updates
> 	* new fields are added to old objects transparently
without touching objects properties
> 	* M-L implemenation will be ready for new classes 
> 	( even if records were created with old API ) 
> 	* we do not deprecate old API for one release and
bring it to live again in another release
> 
> Technically I wil update only mgd_vcreate and
mgd_vupdate functions so we will have new features
> basic support for all old classes with one change.
> 
> My question now is:
> 
> Should I run another two queries when object is created
or updated to get and insert the same guid 
> or to tune old guids functions ( make only two queries
) and make uuid support at the same time?
> 
> Piotras
> 
>
------------------------------------------------------------
---------
> To unsubscribe, e-mail: dev-unsubscribemidgard-project.org
> For additional commands, e-mail: dev-helpmidgard-project.org
> 

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribemidgard-project.org
For additional commands, e-mail: dev-helpmidgard-project.org

Hi,

On 3/8/06, Piotras <ppinfoglob.com> wrote:
> Retrying... ;)
>
> > My question now is:
> >
> > Should I run another two queries when object is
created or updated to get
> > and insert the same guid or to tune old guids
functions ( make only two
> > queries ) and make uuid support at the same time?

I have no clue on what you mean.  Are you
having trouble setting
the correct creator/revisor links?

BR,

Jukka Zitting

--
Yukatan - http://yukatan.fi/ - infoyukatan.fi
Software craftsmanship, JCR consulting, and Java
development

"Jukka Zitting" <jukka.zittinggmail.com> wrote:

> Hi,

Hi,

> I have no clue on what you mean. 

Briefly:

I.
	1.7 - legacy and schema objects can be "transparently
replaced"
	1.8 - we mark old API as obsolete
	1.9 - we implement Midgard Lite like old midgard-php API 
	For me there is some huge logicless step between 1.8 and
1.9.

II.
	Since 1.8 spider admin and Aegir's usage should be
forbidden as those uis 
	creates objects without guids.

III. 
	Since 1.8 we do not use object's identifier as mgd
structure's member but we use full object.
	So when you create person A with spider and you login in as
person A, you use "guidless" person 
	object, and this is quite important for all metadata info.

To sum up:
Either we do mark old API as obsolete and we forget about
Midgard Lite API 
or we do not mark old API as obsolete and we make legacy
code ready for 1.9 now.

Piotras

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribemidgard-project.org
For additional commands, e-mail: dev-helpmidgard-project.org

Hi,

I'm still not sure if I get you, but let's try...

On 3/8/06, Piotras <ppinfoglob.com> wrote:
> Since 1.8 spider admin and Aegir's usage should be
forbidden
> as those uis creates objects without guids.

What do you mean: "creates objects without
guids"? It shouldn't be the
applications task to create the GUID, it should be generated
automatically for each new object by midgard-core.

> Since 1.8 we do not use object's identifier as mgd
structure's member
> but we use full object. So when you create person A
with spider and you
> login in as person A, you use "guidless"
person object, and this is quite
> important for all metadata info.

The full object should always have the GUID, regardles of
what creates
it or how it has been retrieved. A "guidless"
object is always an
error.

BR,

Jukka Zitting

--
Yukatan - http://yukatan.fi/ - infoyukatan.fi
Software craftsmanship, JCR consulting, and Java
development

"Jukka Zitting" <jukka.zittinggmail.com> wrote:

> Hi,

Hi,
 
> > Since 1.8 spider admin and Aegir's usage should
be forbidden
> > as those uis creates objects without guids.
> 
> What do you mean: "creates objects without
guids"? It shouldn't be the
> applications task to create the GUID, it should be
generated
> automatically for each new object by midgard-core.

Spider, Aegir:

$person = mgd_get_person(); /* MidgardPerson */
/* some code */
$person->create();

midgard-core ( when auth is called ) 

MgdObject *object = midgard_object_new_by_id(
	mgd,  "midgard_person",  (gchar *)
mgd->current_user->id);

> The full object should always have the GUID, regardles
of what creates
> it or how it has been retrieved. A
"guidless" object is always an
> error.

const gchar *guid;
g_object_get(G_OBJECT(object), "guid",
&guid, NULL);

/* It deson't make sense to check. Throw error!  */
if(midgard_is_guid(guid))
	g_error("Person object has no guid value");


Legacy objects has guid accessible after guid method was
called and guid value is stored in repligard 
table, while new objects has guid stored in object's table
to avoid multitable selects.

PIotras

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribemidgard-project.org
For additional commands, e-mail: dev-helpmidgard-project.org

Hi,

On 3/8/06, Piotras <ppinfoglob.com> wrote:
> $person = mgd_get_person(); /* MidgardPerson */
> /* some code */
> $person->create();

mgd_get_person() should generate the GUID.

> MgdObject *object = midgard_object_new_by_id(
>         mgd,  "midgard_person",  (gchar *)
mgd->current_user->id);

midgard_object_new_by_id() should get the GUID.

> const gchar *guid;
> g_object_get(G_OBJECT(object), "guid",
&guid, NULL);
>
> /* It deson't make sense to check. Throw error!  */
> if(midgard_is_guid(guid))
>         g_error("Person object has no guid
value");

That check should never fail on Midgard objects.

BR,

Jukka Zitting

--
Yukatan - http://yukatan.fi/ - infoyukatan.fi
Software craftsmanship, JCR consulting, and Java
development

"Jukka Zitting" <jukka.zittinggmail.com> wrote:

> Hi,
> > $person = mgd_get_person(); /* MidgardPerson */
> > /* some code */
> > $person->create();
> 
> mgd_get_person() should generate the GUID.

this is empty constructor. I need to insert guid to
database.


> > const gchar *guid;
> > g_object_get(G_OBJECT(object), "guid",
&guid, NULL);
> >
> > /* It deson't make sense to check. Throw error! 
*/
> > if(midgard_is_guid(guid))
> >         g_error("Person object has no guid
value");
> 
> That check should never fail on Midgard objects.

I know , that's why I wrote this mail.

Piotras

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribemidgard-project.org
For additional commands, e-mail: dev-helpmidgard-project.org