Hi,
Check out the section of the docs on metadata queries. You can
easily get a list of your namespaces.
http://code.google.com/appengine/docs/python/datastore/metadataqueries.html
I may be wrong, but I believe the admin panel's stats cover the
whole app -- not any one namespace. The stats can sometimes take a
while to update.
Ultimately, the choice of using a reference-property versus
namespaces will probably come down to your preferences as much as your
needs. Namespaces give you the ability to do some things very
cleanly, but they also add some restrictions.
Robert
On Sat, Dec 25, 2010 at 04:42, Sarfaraz <[email protected]> wrote:
> Dear Robert,
>
> Thank you for replying,
>
> regarding backups I am still thinking of an efficient way....
> I would be very gald to get your help on that once I finish up with my app
>
> for user authentication I cannot use openid or google user accounts. because
> most of my clients will not have either of them. apart from that each of my
> users (Tenants) will be creating their own Users, Departments, Designations,
> Accounting Heads, Material Types, Etc etc.
>
>
> I also noticed one thing..... the google apps admin panel doesnt show
> statistics for different namespaces except the default one. it also doesnt
> show the namespaces anywhere. This is scaring me away from using namespaces
>
> I am still wondering if I can go with namespaces instead of creating a
> TenantId column
> example : TenantId = db.ReferenceProperty(Tenants) in each entity.
>
>
> Regards
> Sarfraz Farooqui
>
>
>
>
> Warm Regards
> Sarfaraz Farooqui
> --
> Strong and bitter words indicate a weak cause
>
>
>
> On Sat, Dec 25, 2010 at 10:58 AM, Robert Kluin <[email protected]>
> wrote:
>>
>> Hi Sarfaraz,
>> If you read about namespaces, and look at the code a bit, you'll see
>> that they are something like a key-prefix -- just like your appid. So
>> if your data is well suited for that type of compartmentalization, you
>> should have no problems with many namespaces. Keep in mind, it would
>> be difficult to query across (all or a large set of) namespaces;
>> unless you implement your own index to facilitate the query.
>>
>> However you manage your user authentication, I think that approach
>> is probably ok (though personally I would encourage you to look into
>> OpenID or Google Accounts). I do something similar with an OpenID
>> 'authed' app. I store my own 'User' kind and use information stored
>> on the user's entity to set the namespace. Just make sure however you
>> are storing your namespace provides some kind of protection against
>> me 'spoofing' my tenant-id (during login and in regular usage).
>>
>> You might want to mention how you are, or plan to, do your backups
>> if you would like feedback on that. I've got my own backup solutions
>> I use, depending on the app and that type of data you'll be handling.
>> Most other people I've spoken with do too.
>>
>>
>> Robert
>>
>>
>>
>>
>> On Fri, Dec 24, 2010 at 11:01, Sarfaraz <[email protected]>
>> wrote:
>> > Hi,
>> >
>> > I am planning to use namespace_manager to create a multitenant
>> > application,
>> > I have few questions in mind
>> >
>> > 1. is there any limit on the number of namespaces I can create and
>> > use. for
>> > example
>> > If i have 3000 Tenants, Can I create 3000 namespaces to store data
>> > in a
>> > compartmentalized manner for each client/tenant.
>> >
>> > 2. I plan to create an Entity in the Global Namespace which will Store
>> > My
>> > Tenants information. Each Tenant can create his own users , I am
>> > managing
>> > the user accounts on my own instead of using User object or openid..
>> > When
>> > any User logs in, I will store his Tenant Id in a Session (Using
>> > GaeSessions). and when ever I have to read or write data to entities I
>> > will
>> > set the current name space to the Tenant Id. Is this a good way, or is
>> > there
>> > any thing better.
>> >
>> > 3. Finally I would like to know things I should be aware of while using
>> > Gaesessions and Namespace manager, what kind of problems I may face in
>> > the
>> > future or day to day management activities. like backups, restores etc.
>> >
>> >
>> > Thanks and Regards
>> > Sarfaraz Farooqui
>> >
>> >
>> > Warm Regards
>> > Sarfaraz Farooqui
>> > --
>> > Strong and bitter words indicate a weak cause
>> >
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> > Groups
>> > "Google App Engine" group.
>> > To post to this group, send email to [email protected].
>> > To unsubscribe from this group, send email to
>> > [email protected].
>> > For more options, visit this group at
>> > http://groups.google.com/group/google-appengine?hl=en.
>> >
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Google App Engine" group.
>> To post to this group, send email to [email protected].
>> To unsubscribe from this group, send email to
>> [email protected].
>> For more options, visit this group at
>> http://groups.google.com/group/google-appengine?hl=en.
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Google App Engine" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to
> [email protected].
> For more options, visit this group at
> http://groups.google.com/group/google-appengine?hl=en.
>
--
You received this message because you are subscribed to the Google Groups
"Google App Engine" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/google-appengine?hl=en.
